Solution Suggestion Required !!

[SandeepKSingh]

You must update an Incident, create 3 related RITMs, and upsert 150 CI relations atomically. If any step fails, everything must roll back. How would you implement this in scoped apps using GlideRecord, background scripts, or GlideTransaction patterns—without relying on Flow Designer? Discuss pitfalls around BR recursion and after-commit work.

[Ravi Gaurav · Accepted solution]

Hi @SandeepKSingh 

Solution approach

1. Use a Script Include to handle everything in one try/catch.

2. Keep arrays of created sys_ids (RITMs, CI relations).

3. If any step fails:

   • Revert Incident to old values.

   • Delete inserted RITMs.

   • Delete inserted CI relations.

4. Guard recursion with a session flag (gs.getSession().putProperty()).

5. Suppress after-commit notifications during this batch (add conditional checks in BRs).

[Ravi Gaurav · Accepted solution]

Hi @SandeepKSingh 

Solution approach

1. Use a Script Include to handle everything in one try/catch.

2. Keep arrays of created sys_ids (RITMs, CI relations).

3. If any step fails:

   • Revert Incident to old values.

   • Delete inserted RITMs.

   • Delete inserted CI relations.

4. Guard recursion with a session flag (gs.getSession().putProperty()).

5. Suppress after-commit notifications during this batch (add conditional checks in BRs).

[SandeepKSingh]

Thanks ravi as usual.. can you explain the gs.getSession().putProperty()).

[Ravi Gaurav · Accepted solution]

gs.getSession().putProperty() is a server-side method in ServiceNow used to store a custom property within the current user's GlideSession. This property can then be retrieved later in the same session using gs.getSession().getProperty().

[SandeepKSingh]

Thanks @Ravi Gaurav  both helped.. I implemented and it worked for me as per you suggestion. Please continue helping us ..