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!

[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.

[Mark Manders]

This doesn't make sense. A catalog item should have all questions needed to fulfill the request. And in case more information is needed, you can ask that through comments so the opened_by can update the request. Surveys don't make sense in your use case. That implies you know what needs to be added, so you should have requested that upfront.

[Dr Atul G- LNG]

Agree with you @Mark Manders 

Creating a new RP would introduce technical debt and is not a good approach. It would also create confusion for users about which process to follow — the existing Record Producer or the Request process — especially regarding state updates @Ankit Balapure 

[mahesh_vavilal1]

Agree that Service Catalog Item should follow a predefined process/flow.  Having said that, I did implement something similar few years ago where the workflow is driven based on the user's additional input and it was done using Assessments.

Request Submitted --> Approval --> SCTASK (Initial Analysis - Group A) --> Assessment sent to user --> SCTASK (Group B or Group C based on the Assessment feedback).