Description field in CSM Case?

[Lars Bolk]

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?

[sanjaygupta]

From what I’ve seen, the absence of the Description field appears to be intentional in the out-of-the-box CSM Case form. ServiceNow uses Short Description for a brief summary and Additional Comments for detailed information shared by the customer.

• Use Short Description for a quick issue summary.
• Use Additional Comments for the customer's detailed description.
• Use Work Notes for internal troubleshooting details.
• Add Description only if you need a separate field to store the issue details.

I wouldn't add Description by default. If you decide to add it, check the ACLs and test the changes in a sub-production instance first.

Do like if you find this helpful.

[Kieran3]

Hi @Lars Bolk,

I'd noticed this myself whilst working on CSM. My understanding is that the OOB design uses 'Additional comments' for the customers initial description and subsequent updates. Because it is a journal field, it builds a chronological record of the conversation without deleting earlier information which provides the agent and the customer complete transparency on everything as it happened. For example:

Customer submission: “The device stopped reporting data after yesterday’s software update. Restarting it has not resolved the issue.”

Agent: “Could you confirm the software version and the approximate time the issue started?”

Customer: “The device is running version 4.2.1. The issue started at approximately 14:30.”

Agent: “We have reproduced the issue and escalated it to our engineering team. We will provide another update when the investigation progresses.”

Resolution communication: “Engineering has applied the configuration fix. Please confirm that the device is now reporting correctly.”

Customer: “Confirmed, the device is reporting correctly again. The case can be closed."

Meanwhile, agents can still store work notes that are private from the customer. Short description just acts as concise summary.

You could add a description field but you'd be responsible for the ACLs and maintenance around it whereas the Additional comments will function as the CSM model as intended for the customer.

Hope this helps! If you found it useful, feel free to leave a 👍 Kudos. If it answered your question, accepting it as a solution helps others find the answer too.

[Lars Bolk]

Description field can be added, with the extra effort of staying in control of having proper and correct ACL's. But why do that if it was not the intended way of working from the CSM application creators?
There are some people arguing that you should use the Description field, and that it is indeed best practice - even though you need to add that field and capability to the CSM Case form yourself...? Is it simply from being used to always having a Description field (e.g. from ITSM Incident or HR Case)?
So I'm trying to get to the bottom on this. 🤔

[sanjaygupta · Accepted solution]

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.