Title Best approach to collect additional information after RITM submission – Survey vs Alternative?

[Ankit Balapure]

Hi Everyone,

I have a requirement where a user submits a request through a Catalog Item (for example, requesting software installation).

Current Process

1. The requester fills some initial variables in the Catalog Item form and submits the request.

2. After submission, an SC Task is created.

3. The Assigned To person needs additional information to proceed with the task.

4. Currently, the Assigned To user contacts the requester (via chat/email) to collect the required details.

5. After receiving the information, the Assigned To user manually updates the variables on the SC Task.

This process is time-consuming and inefficient.

---

Proposed Approach

We considered triggering a Survey after the request is submitted so the requester can fill in the additional information. The responses would then automatically update the variables on the SC Task.

However, while designing the survey, I noticed several limitations:

• No support for Rich Text question type

• Cannot make questions read-only

• Cannot show dynamic header information like:

  • RITM Number + Short Description + Requested For

• Limited flexibility compared to Catalog variables

---

Requirement

The service owner wants the same behavior and experience as Catalog variables but inside the survey.

---

Question to the Community

Has anyone implemented a similar solution before?

Specifically, I would like guidance on:

• Whether Survey is the right approach for this use case

• If there are better alternatives to collect additional information from the requester after RITM creation

• Any best practices or architecture recommendations

Some options we are considering:

• Survey

• Record Producer / Catalog Item triggered later

• Other ServiceNow-native solutions

Any suggestions or experience with similar implementations would be greatly appreciated.

Thank you!

[Ankur Bawiskar]

@Ankit Balapure 

Survey is not good here.

My thoughts

-> you can use record producer and they select their request submitted i.e. select the RITM

-> you show set of variables to user on that record producer and then once submitted you can update the RITM variables

-> the dummy record on target table can be used as placeholder to identify which end user submitted the correction data

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Ankit Balapure]

Hi @Ankur Bawiskar ,

Thank you for the suggestion.

Just to clarify, for implementing this solution using a Record Producer, we would need to specify a Target Table. That means we would either need to create a separate custom table to store the responses or select an existing table.

In this scenario, the goal is to capture additional information from the requester and update the variables on the existing SC Task / RITM, rather than creating a new record.

So I wanted to check:

• Do you recommend creating a separate custom table just to capture the responses and then updating the SC Task variables through script/flow?

• Or is there any existing table (for example related to the request) that could be used as the target table for the Record Producer?

Could you please clarify the recommended approach for this?

Thanks in advance.

[Ankur Bawiskar]

@Ankit Balapure 

no custom table required

you can use sc_req_item as target table and stop the record insertion in record producer script

simply use record producer to grab the variable input and update RITM with no dummy RITM creation

something like this in record producer script

// your logic to updat RITM

current.setAbortAction(true);
producer.portal_redirect = "/esc";

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Dr Atul G- LNG]

Hi @Ankit Balapure 

The purpose of this system is to gather information after a record is closed. Currently, your approach is ad-hoc. Request management should follow a standard process: once a record is submitted, the team needs to work on it using a consistent approach, asking the user for updates in a controlled manner.

It’s better to build a form with the required variables so the user can submit all information in one go, rather than multiple times. This will improve the user experience, reduce the number of times agents need to reach out for updates, and minimize technical debt and workflow delays.