Migrating from IT Service Management to Customer Service Management - the "right" way

Note: This is currently a work in progress article because I want to add documentation and code snippets.

Customer Service Management (CSM) is one of ServiceNow’s “hot” products. Unfortunately, it doesn’t play nicely with IT Service Management (ITSM) out of the gate. One day ServiceNow may make a utility service that will help with migration, but until then - we are stuck fending for ourselves.

This blog series is dedicated to how to effectively migrate a ServiceNow ITSM to CSM instance (Quebec+). This blog post focuses on the plan and the first phase.

Plan out the project and release it in phases.

This may sound boring or ridiculous, but don’t try to big bang this (unless ServiceNow isn’t mission critical yet). Things will break.
I recommend releasing to prod this in 4 phases:
1. Turn on plugins, get roles setup correctly, and move users (if necessary)
2. Create Cases and Workspaces
3. Create Portal pages
4. Onboard an organization
After each phase do a clone down from prod to dev

Dealing with the Context Security Plugin for Users and Roles

The hidden mine field with CSM is the Context Security Plugin. Essentially what it does is require every user in the system in the role to have a role. In the IT Service Management space, that concept doesn’t normally exist. In ITSM, you have itil or no role (in most cases).

To combat this, the following things should be done:

Roles should be created for each affiliation in your system (depending on your industry). I’ll have a few dedicated posts for each industry, but for example sake, let’s say you have salary employee, full-time hourly employee, part-time hourly employee, and intern (exclude contractors for now). This will cover your internal employees. As for external parties, let’s say you have direct customers, vendors, and partners. In the future, you may want different access or experience for these folks - so let’s build the muscle now.
Create groups for each of these affiliates types, assign the role, and create a fix script to move users into the group.

Dealing with the Context Security Plugin for the Platform

So you finally have your users and groups settled, now it is time to fix the parts of the platform that are probably broken.

The 5 main areas that are probably broken:

Portal Pages
Portal Widgets (and potentially Widget Instances)
Catalog Categories
Catalog Items
Knowledge Bases

We need to add those custom roles to each of those 4 items. You will want to write a fix script for these or if you don’t have a lot of them, manually update them. Some may use the “roles” field or others may use “Available For/Can Read” user criterias.

Turning on Plugins

Now that we have all the roles setup, we can finally install the critical plugins:

Customer Service Management (com.snc.csm)
Customer Service Case Types (com.snc.csm_case_types
Customer Central (com.sn_csm_customer_central)
Business Location (com.snc.business_location)
Customer Service Base Extension Entities (com.snc.cs_base_extension)
Service Organization (com.snc.service_organization)
Customer Service Household (com.snc.household)
Case Action Status (com.snc.csm_action_status)
CSM Extension for Proxy (com.snc.csm_proxy_contacts)
CSM Contributor User (com.snc.csm_contributor_user)

Once those plugins are installed, the real fun begins.

Adding the out of box roles to the custom roles

Now the hard part, deciding which out of box roles to give each affiliation. Let’s start with the internal employees.
1. The contributor users document has some good information about this, because it depends on what role internal employees play within your organization.
2. If the group doesn’t plan on creating tickets on behalf of others: sn_customerservice.self_contributor is the way to go
3. Assign this as a “contains” role under the custom internal roles you created
4. These users will live on the sys_user table
Let’s focus on the external parties next
1. The industry data model has good supporting documentation on this because there are two main use cases: households w/ consumers OR accounts with contacts
2. The easiest way to differentiate them is to answer the following questions:
  1. Will someone need to create cases on behalf of another organization (vendors/partners,etc)? If yes, accounts w/ contacts are where they go
  2. Will someone just need to buy goods or services for themselves? If yes, households w/ consumers.
3. Contacts get the role of “sn_customerservice.customer” and they live on the customer _contact table. They get associated with accounts (customer account table). Think of these accounts as vendors, organizations, partner companies, etc. Customer acccounts table extends the core company table.
4. Consumers get the role of “sn_customerservice.consumer” and they live on the csm consumer user table (login record) and the csm consumer table (profile). They get associated with households (household table). Think of these as households “Kersch family” or “Musk family” and they have different consumers with different relationships underneath these.
So once you know which internal and external parties fit, add the out of box role to the custom role you created. If you find there are “edge cases” then your affiliation types need more refining.
P.S. Make sure the “guest” user doesn’t have a role (this is a special account that will affect email if it has a role)

Handling transform maps

Now that you have your users, affiliations, and roles mapped out. Make sure to update the transform maps. Your transform map has probably 1 map for the user table, so you may want to split it out into at least 4 transform maps (1 for each table + consumer profile)