- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Introduction
Record Summarization is one of the most visible and valuable Now Assist capabilities, especially when organizations start rolling out AI at scale. The Summarization skills offer a good configuration framework, but sometimes requirements exceed what they provide out of the box. There are some tweaks you can apply to the skills that are not always obvious, yet they are still configurations.
This article consolidates learnings from an Incident Summarization implementation, but it will serve as an example for other Record Summarization skills as well, and explains, in practical terms, how you can configure the Incident Summarization skill beyond the Now Assist Admin console.
Business Requirements and Configuration Context
In this use case, we need Incident Summarization to behave differently depending on context. Specifically, we want:
- Different input fields when an Incident is a Major Incident versus a non-Major Incident.
- The same Incident lifecycle states (New, Work in Progress, Resolved, Closed).
This requirement goes beyond the default Out‑of‑the‑Box (OOTB) configuration, where a single Input Template per state is used.
How Incident Summarization input configuration works
To configure the skill, the first thing you need to do is to make a copy of the skill as usual.
Incident Summarization is configured through skill configuration records on sn_nowassist_skill_config table, like other skills including our copies. For this skill, input behavior is controlled through “Record Summarize Templates” associated with the skill configuration on the Now Assist Skill Config Var Sets related list.
These Input Templates define:
- Input Field Description: which Incident fields are passed to the model and the descriptions to the LLM.
- Condition: under which conditions a template applies (for example, based on Incident state or Major Incident flag).
- Prompt filter: The condition to select the prompt used for this template.
- Order: The order in which appear in the Now Assist Admin console.
Cloning Input Templates
Since our requirement is to have different input fields when an Incident is a Major Incident versus a non-Major Incident, we need more Input templates that the ones coming on the OOTB skill, and that is something we cannot configure directly in the Now Assist Admin console.
Rather than modifying the Input templates directly, what we need to do in this case is:
- Copy the existing OOTB Record Summarize Templates (New, WIP, Resolved, Closed).
- With those copies we have additional templates per state (for example, “New – Major”).
- Add conditions such as “Major Incident State is Accepted” or “is not Accepted”.
- Keep the same prompt reference if the summarization logic does not need to change.
This approach allows the skill to dynamically select the correct Input Template at runtime based on Incident data.
Once you copy the Input Templates in the backend, they will show as configurable options in the Now Assist Admin console.
In this example we add Location as new Input field. I recommend you to add in the Field description in which section it should appear if you are using the OOTB prompt.
For the same State, be sure that the conditions are mutually exclusive.
Using the same prompt with different inputs
To follow this section, I recommend you to open any Record summarization prompt in your instance and check the Prompt itself to review the details, following the instructions below.
It is also important to have clear the concept of "Input Template / Record Summarize Template" that was explained previously as well as the difference between Condition and Prompt filter.
One thing to keep in mind are the Prompt usage conditions. From the Now Assist Admin console you can go to Customize prompt and open any of the prompts. In my example I will open "Work in progress" clicking on Edit prompt in Now Assist Skill Kit.
That will open the prompt on Skill Kit and you will be able to check the Prompt usage conditions, on the right side panel, which is the filter considered to use one prompt or another.
A key question raised during the implementation was whether different Input Templates require different prompts. The answer is:
- It is not mandatory to use different prompts.
- A single prompt can work with multiple Input Templates as long as it makes sense considering the input fields and the condition of the prompt aligns with the condition of the Input template.
- All fields included in the Input Template are passed to the prompt automatically, as long as the prompt references remaining attributes, and those additional inputs are configurable through the Now Assist Admin console.
In this case, all prompts already include placeholders such as: “{{other_fields.all_remaining_attributes}}” and “{{relatedlists_data.all_remaining_attributes}}”.
Because of this, separate prompts are not required for Major vs non‑Major Incidents in this specific use case, because we only need to have different inputs for different conditions, and those new inputs will be considered on those placeholders anyway. Let's see an example.
For instance, have a look at the Prompt usage conditions of the Work in progress prompt
Then look at the configured "Record Summarize Template" at Now Assist Skill Config Var Set.
For the Work in progress state, we have "Work in progress":
And "Work in progress - Major":
As you can see in the Prompt filter we have the same condition that match the Prompt usage conditions on the Prompt configuration.
That is the key difference between "condition" and "Prompt filter", the first is the one used to select the Input template. Once selected, the Input fields configured there will be taken into consideration, and the prompt used will be the one that matches the condition of the "Prompt filter". And that is why in our case, where we want to have the same prompt but different input fields, we can leverage the same prompt, leaving the same Prompt filter to both Record Summarize Template records.
The only caveat is that the added inputs might not appear on the summary due to the format of the output that is described in the OOTB prompt. To ensure new fields appear in the summary you can add instructions in the Field description explaining in which section they have to appear. For instance:
If you experience the new inputs are not added to the result you might need to clone the prompt following the instructions given by the system and use the Prompt usage conditions together with the Prompt filter on Prompt and Record Summarize Template configurations respectively.
Important detail: field ingestion order and truncation risk
In the OOTB prompts, additional input fields are appended to the prompt after the Activities content ({{activities}} placeholder). If the Activities section is very long, newly added fields may be truncated and never reach the model.
To ensure your additional fields are considered:
- First, test with real customer data to confirm whether truncation actually occurs.
- If needed, clone the prompt and move critical fields above the Activities section.
This ensures high‑priority fields are always included in the summarization context.
Recommended validation approach
Before deploying changes to Production, the following validation approach is recommended:
- Start by cloning Input Templates only.
- Reuse the existing prompt.
- Test summarization output using real Incident data.
- Evaluate whether important fields appear consistently in summaries.
- Only clone and modify the prompt if truncation or relevance issues are observed to minimize the maintenance.
This minimizes configuration complexity while still allowing advanced configuration when necessary.
Key takeaways
- You can create multiple Input Templates per Incident state.
- Conditions (such as Major Incident vs non‑Major) determine which Input template is used.
- Prompts can be reused across templates when designed correctly, consider the Prompt usage conditions and Prompt filter.
- Field order in the prompt matters and can affect summarization quality, watch out for the Activities length.
- Always validate behavior with real data before over‑engineering.
- 306 Views
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
