- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
In a greenfield out-of-the-box ServiceNow CSM implementation there is no Description field, only a Short Description field, on the CSM Case form. Is this intentional, and would it be considered best practice to add the Description field or not? Of course the Description field is available, as it exists on the Task table, and the CSM Case table is extended from the Task table.
Instead there are indications that the Additional Comments is the proper field to use for extended case/issue description.
- The Description field is not (ootb) on the Core UI CSM Case form view, or the Workspace CSM Case form view.
- There are no CSM-related ACL's for the Description field, so if adding the field new ACL's need to be added in order to ensure proper access for all CSM roles.
- The Documentation Portal for CSM do not mention the Description field.
- Ootb Record Producers in CSM, e.g. "Create case for a product", map the Description variable to the Additional Comments field.
- No mention or instruction in Best Practices (Process Guides / Implementation Guides / Implementation Insights, Deployment Guides / Scoping Guides / Process Workshop Presentations / Starter Stories) to add the Description field.
If adding the Description field is considered being best practice, then it is close to impossible to understand that from the available official documentation material.
What is the intended way of working in CSM Case Management when extended case/issue description is needed - more than what can fit in Short Description?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
The Description field is inherited from the Task table, but that doesn't automatically make it a CSM best practice. ServiceNow CSM commonly uses Short description to summarize the issue, Additional comments for customer-facing communication, and Work notes for internal updates.
- Use Description only if you need a separate field for detailed issue information.
- Review ACLs to ensure the field is accessible only to the right users.
- Test changes in a sub-production instance before deployment.
The key point is that adding the field is a design choice, not a universal CSM requirement. The right approach depends on your case-handling process and the CSM experience you're using.
Hope you find this helpful.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Friday
I appreciate the responses, however, I want to warn about setting up the custom ACL's. If you create a "write" ACL on the case table (or anything extended from it) and you provide it to the sn_customerservice.customer role, this now becomes a LICENSED role - meaning ServiceNow will want you to pay for customers who are logging in (at a fulfiller license level!)
We haven't tried changing it yet, but we will be trying to use "create" instead for the customers.
