Case Types - Best Practices to Implement Case Types

[Erik Ryan]

Hi All,

White paper now available: Case Types - Best Practices to Implement Case Types

Blurb: Case types are needed when an organization has different processes for supporting customers across multiple departments, business units or products. CSM customers span multiple industries, and each industry has a diverse set of processes for end customers. Depending on how distinct these processes are, each type of process could be a separate case type.

Feedback is welcome!

Thanks, Erik

[Jennifer Budurk]

One of the best documents I have seen in 3.5 years.  So thorough.  The only feedback I would give would be any call outs relative to industry case type extensions and if all the same rules of inheritance apply and if they are coming from the base customer service case or if they only inherit things from the original industry case.  I will be on the look-out for more docs that you author!!!!  

[Erik Ryan]

Appreciate the positive feedback Jennifer! I'm looking into your question and will reply here + add to the document as necessary.

Thanks, Erik

[Erik Ryan]

Hi Jennifer, a response from a fellow SME...

>>The short answer is yes, all the same inheritance logic will apply to case types as they do to any other table in ServiceNow. 

Most functionality will be inherited when extending tables. There are obvious things like fields that will come from parent tables, but those can be overwritten (i.e. labels, reference qualifiers, etc.) at the extension level. Some pieces of functionality like client scripts have a flag to determine if they should be inherited by the extension tables. Other things like UI Actions will always we inherited by the extension tables. 

[Michael Everson]

Thanks for preparing this guide, it seems like a great springboard for the work plan I am building now. I've done new task types many times before, but CSM has a quite a few moving parts, so I appreciate you taking the time to flesh it out like this.

[Erik Ryan]

Hi Michael, thanks for the positive feedback here hope you find it useful!

[Michael Everson]

After going through the process of adding a handful of case types, I wanted to jot a couple of notes in case they are useful for anyone... or should I say 'in sn_customerservice_case they are useful for anyone'... 😛

CSM Query Rules

I noticed that this guide does not really deal with the CSM Query Rules feature used in CSM and how to adapt it for your case type.

I think it would be common to use a role to limit visibility of certain case types to a subset of fulfillers/agents. You would probably do this with a CSM Query Rule for that role, to scope access down.

If you do this, you will need to add your new role to the script in the ACL with sys id 4056c766b3ba1010700b4d43c6a8dced (or deactivate this one and make a copy to edit). This ACL uses the query rules to restrict access to agents who pass the query condition, but only for roles listed.

Actionable Case Flows

I think most installations of CSM would have the actionable case flows updating the 'Action Status' and 'Needs Attention' fields. None of these flows work with case types. I had to make new copies with the flow option checked to run on extended tables. Also note that some of these flows check the table type in the flow steps themselves, so they all have to be read carefully. Make sure to exercise these flows so that you can approve the cross-scope access.

Inbound Actions

Specific inbound actions will need to be made for each case type, if you are using these for CSM.

If you are basing these on the out of the box actions you will need to add the 'sn_customerservice.' to many of the script includes used in the condition field and verify that you have Cross Scope access to all of these as they do not seem to auto-populate - you have to manually create them. You may find it easier to just keep these rules in the Customer Service scope, rather than you case type scope.

I hope this will save someone some pain 🙂

Case Type SLAs

Remember that out of the box, Case Types have their own SLA processing rules that do not match the behaviour described in the general platform documentation. You can see the definition in the 'SLA Condition Type' menu. Each SLA definition can have one of these referenced in its 'Condition Type' field, or be blank to use the platform default instead.

Best of luck with your case type adventure.

[danwright]

Hello,

Thank you for the white paper and the responses. Any changes in Tokyo to this approach? If so will there be an updated version? Thank you again for this great documentation!

[Julie Leung]

Hi @Erik Ryan,

Thank you for this excellent guide.  I read through it but I can't find my use case in it and wondering if you have any thoughts.

I am attempting to enable the Response Templates button (which brings up the feature that used to be called Templated Snippets) in the Contextual Side Bar, in the OOTB CSM/FSM Configurable Workspace, which is in the CSM Configurable Workspace scope, for my Case Type which is an inheritance off of sn_customerservice_case, and in its own custom scope.

Do you have any thoughts on best practises to do this?  I can either edit the existing "Response Template Screen" UX Screen (sys_ux_screen) record (sys_id = 8b7f80f553c3101043d7ddeeff7b12e8) and change the Screen Condition from:

parent.table=sn_customerservice_case

to:

parent.table=sn_customerservice_case^ORparent_table=x_mycustomscope_mycustomtable

For the above, I do not know if ServiceNow intends for customers to change this OOTB UX Screen record to include our custom tables, since this record would need to be modified within the CSM Configurable Workspace scope, in an Update Set as this scope is not editable within Studio. 

Or, I can create a new UX Screen, potentially within my custom scope, which sets my Screen Condition to point to my custom table name.  Putting this new record in my custom scope may cause cross-scope permissions issues or force me to create duplicates of additional components (Screen Applicabilities, Table Configuration, Contextual Side Panel action assignments, etc. etc.) that might not otherwise be needed.

Do you have any thoughts on the best practise for enabling this Response Templates button on the OOTB CSM/FSM Configurable Workspace, for my Case Type which is in its own scope?

Thank you in advance!

[Erik Ryan]

Hi Julie, glad the guide has been useful! I needed to consult with my colleague on this one (Parag Mone). Here was the response:

"CSM/FSM Configurable Workspace" has a UX Page Property "contextualTableConfigMapping_main". To enable Response Template and Agent Assist for the Case Types, modify this property with the respective Case Type.

Let me know how that works out?

-thanks

[Julie Leung]

Hi @Erik Ryan, thank you for passing that bit of information on from your colleague.  Unfortunately, I'm not able to translate this to action.  I found some information about UX Page Properties in Ashley Snyder's article Workspace App Shell UI Page Properties.  Though I am not that familiar with UI Builder yet, I was able to navigate in UI Builder in the CSM/FSM Configurable Workspace experience, and ultimately locate the UX Page Property table (sys_ux_page_property).  Looking through the list of all UX Page Properties, I am not able to find any with the name contextualTableConfigMapping_main on any page (CSM/FSM Configurable Workspace, or any others, for that matter).  I couldn't find a match when searching for contains "contextualTableConfigMapping_main" in the Value or Required Transalations fields.  And nothing containing "template" or "assist" in the Description field, either.

Does this UX Page Property record with name = contextTableConfigMapping_main need to be created?  If so, must it be created in the CSM/FSM Configurable Workspace scope captured within the Default update set in this scope?  If so, what should the value be set to and what is the format if there are multiple Case Types that need to have this button enabled for it, while also maintaining the enablement on base Case sn_customerservice_case?

Thank you for any help you can provide.  There are not docs about enabling this, it's not in the CSM Implementation curriculum, and it's very hard to read between the lines of the information about the Next Experience framework in the Next Experience COE, to know how to make this happen properly.  I appreciate any detail you can provide further.

(PS - probably not the right way to do it, but I was able to get this working by creating a duplicate UX Screen record in my Case Type's application scope, pointing to all the same components as the OOTB UX Screen for Response Template Screen record (sys_id =8b7f80f553c3101043d7ddeeff7b12e8) which point to components in CSM/FSM Configurable Workspace scope.  BUT, I don't think this is the right "best practise" way, given Parag's comments).

Thank you,
Julie

[Erik Ryan]

Hi Julie, Parag passed this extra bit along today. Yes it appears the UX Page Property needs to be created. Apologies for passing you this piece meal, I just wasn't privy to the complete answer but wanted to pass something along to you yesterday.

Below is at least a little more of a complete answer I believe, let us know how you get on...

•To configure "Agent Assist" and "Response Templates" in the Configurable Workspace for given Case Type, navigate to "Now Experience Framework -> Experiences", and open UX Application record "CSM/FSM Configurable Workspace".

•Navigate to related list "UX Page Properties", create a new UX Page Property "contextualTableConfigMapping". 

•Modify the value to include the appropriate Case Type

[{

"agent_assist": [{

"table=your_case_type_table": "0a73bc83c3041300e2fd5cb981d3ae29" //Contextual search - Table Config Record Id

}],

"response_template": [{

"table=your_case_type_table": "5f0a5f7e77840010ec75945caa1061a5" //Contextual search - Table Config Record Id}]}]

•If needed, you can also define Contextual Search Table Configuration for both Agent Assist and Response Templates

[Julie Leung]

Hi @Erik Ryan, thanks for the follow-up with the format of the JSON.

I created the entry, and presumed it needed to be in the CSM and FSM Configurable Workspace Foundation scope, per below.  (Rest assured, my table name is filled in correctly on platform.  It is the table name of my Case Type which is extended from sn_customerservice_case, but I just blanked it out in my screenshot for privacy reasons):

Unfortunately, it's not working.  Viewing my Case Type in the OOTB CSM/FSM Configurable Workspace, no Response Template (or Agent Assist) button appears in the contextual side panel.

A couple questions:
1.  I'm assuming I don't need to create a new Contextual Search Table Configuration record, and can leave the reference to 5f0a5f7e77840010ec75945caa1061a5 in place, since this is the OOTB one for the base Case table, is already configured how I want it, and using this existing table configuration worked when I created a duplicate UX Screen with parent.table = [my_case_type_table_name].

2.  I'm assuming I don't need to include the agent_assist object/array entry if I don't need that enabled on my Case Type, but I did include it above just to ensure I was following Parag's directions.

3.  I'm assuming I don't need a Route, but I did also try it with Route = "Record", and that didn't make it work either.

4.  I'm assuming that this new UX Page Property record should be in the CSM and FSM Configurable Workspace Foundation scope, and that any additional tables I want to enable the Response Templates button for, I just would need to add an additional Javascript object for that table, in the "response template" array.

Thank you for helping with this.  I am hopeful this thread will eventually serve as makeshift documentation for other people who have the same need.

[Erik Ryan]

@Parag , are you able to lend further comment here? -thanks

[Brenda Williams]

@Erik Ryan we are looking at implementing CSM and struggling with using case types as the majority of our cases created today (custom case application) are created based on inbound emails so how would we properly identify what case type to use from an inbound email? 

[Stijn Verhulst1]

@Julie Leung To enable the Response Templates button on the Contextual Sidebar of the OOTB CSM/FSM Configurable Workspace for Case Types, I experimented using different approaches ending up with different conclusions.

Approach 1: Following the instructions of the following ServiceNow Support article is not feasible: Response Template contextual side bar action not available for case types

That is because it doesn't suit a use case when a case type must apply a specific search context and it enables the usage of response templates to any user that has access to the CSM/FSM Configurable Workspace.

Approach 2: In my Tokyo GA instance the contextualTableConfigMapping_main UX Page Property was available OOTB but modifying it according to the instructions mentioned earlier did not work out.

Nor did the addition of a custom contextualTableConfigMapping UX Page Property, as mentioned earlier, neither. With or without the contextualTableConfigMapping_main UX Page Property.

On that note: the scope of the configurations didn't matter.

Approach 3: I created a new UX Screen, within the same custom scope as my newly created case type, as a duplicate of the Response Template Screen OOTB UX Screen. This solutions works fine after modifying the parent.table value to my case type table within the new UX Screen's Screen Conditions. Also, when desired that is, the desired Contextual Search Table Configuration record can be set by modifying the cxsTableConfig property within the UX Screen's Macroponent Configuration.

Also, I noticed that the OOTB Complaint and Onboarding Cases, available through the ServiceNow Store, use the exact same approach. Hence, it feels as if this approach is the advised one (?).

@Erik Ryan FYI @Parag Can you confirm these are the right conclusions?

One more tip: Response Templates defined for the sn_customerservice_case table will still be shown for any case type. If you want to avoid the latter there are 2 approaches:

1. You create your own Table Configuration with its own Search Context (can be in the same custom scope as the case type's one).

2. If you use the OOTB Response Templates Table Configuration, you can create a new implementation for the sn_templated_snip.response_template extension point by defining your own query logic within the implementation's query function (can be in the same custom scope as the case type's one).

Hope that helps to bring some clarity!

[Julie Leung]

@Parag(Mone), @Erik Ryan We are about to implement @Stijn Verhulst1's Approach #3, which is consistent with my first attempt that I got to work in my Sandbox instance but questioned whether it was best practise.  Seeing as the OOTB Complaint and Order Case Types implemented by ServiceNow utilize this same approach (as reported by Stijn) and the Approach ##2, originally suggested by Parag and yourself, does not work for me or Stijn, I think it is best to utilize Approach #3 as well.

Do you have any final thoughts on the advisability of using this approach before I pull the trigger?

Thank you for your help,

Julie

[davitvoski]

The UX Page properties are located in sys_ux_page_property  table

[denisf88]

@Stijn Verhulst1 @Erik Ryan I'm struggling to get the response template working on case types. None of the 3 options mentioned above seem to work. All Case Types are in the same scope as the default cases (Customer Service) but no matter what I do it seems to have no effect on the contextual sidebar. 

As a test I even disabled the UX screen, even this had no effect, it still shows and works on the (sn_customerservice_case) cases. Its almost like the changes are not being applied.

Any suggestions ?

[denisf88]

got it working, only doing step one of this https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1121743 is sufficient

however, it didn't do anything initially,  going to applications and then repairing the com.sn_templated_snip application fixes the issue, its almost like you have to repair the application every time to apply the changes made. Seems a bit buggy to me

[Kasper XYZ]

Hi
I've implemented a case type for my process and I want this to be default when creating a case. I would prefer not to introduce the type selector. Any ideas on how to do this? I can see that this is mentioned in the guided setup, but not any details on how to do it 🙂

Thanks.

[Ankur Bawiskar]

@Kasper XYZ 

Did you create case type and service definitions to it?

what was your exact setup?