Rejected Tickets and Workflow

Ace009 · 3 weeks ago

Anyone here work in an environment where if a ticket's Approval is rejected, it gets sent back to the submitter for a "rework" and resubmitting that same ticket record? Im used to just telling the user to submit a new ticket with the proper information but I dont have that choice here.

The issue is because I use a record producer, the user will have to update entries in the question_answer table. For my use case, because there's a dedicated table with dedicated fields for this ticket type, I just use the Form widget to allow the user to modify and resubmit. The issue with this is that OOTB the Portal is designed with Catalog Items in mind for things like Ticket Details and Approvals showing the Variable/Option values. So even if the user updates the ticket's fields, the variables are still showing the initial data.

I was wondering if there's a better way to handle this scenario that Im not seeing. I could completely go full Form eventually and just not deal with record producers. Ill still have to update the widgets that display the variable data and replace it with something useful. But then I lose functionality like Multi-Row Variable Sets...

AnkaRaoB · 3 weeks ago

Hi @Ace009 ,

Yes, this is a common challenge in environments that allow rework after approval rejection, especially when using Record Producers.

What you’re seeing is expected OOTB behavior. Service Portal is designed mainly around catalog items and variables, so even if you update the underlying record fields, the portal widgets will continue to display the original values from the question_answer table. These don’t get updated automatically when the record changes.

Because of this, most teams don’t try to keep variables and fields in sync after submission. It quickly becomes complex and fragile, especially with MRVS.

The most practical approach is:

Use Record Producers only for initial creation
On rejection, route users to a Form widget (or custom page) to update the actual record fields
Hide or stop using variable-based widgets once the ticket is in “Rework” state

This way, the UI matches the real source of data.

Trying to update question_answer during rework is possible, but usually not worth the long-term maintenance cost.

If this answer resolved your question, please mark it as solved to help others in the community.

View solution in original post

lauri457 · 3 weeks ago

You can just add the variable editor formatter to your view on your rp target table. It works in portal

Configure the default variable editor for other tables • Zurich ServiceNow AI Platform Capabilities ...

Without knowing specifics, process wise it would probably be way better to just cancel the ticket. Just make it easy for users to resubmit without having to duplicate their effort. You can provide them a url that prefills the variables with their previous input using the sysparm_variable_values url parameter for example.

This way most likely makes for less complexity, easier config, better metrics, uniform process etc etc