Unexpected behavior of the "Service Catalog" trigger in Flow Designer

[Peter Shearer]

Hello, All --

Very novice ServiceNow user here.

We had a bunch of (poorly designed) Catalog Items that created RITMs for groups, and nothing else.  There were no workflows associated with the items, and through that we've generated thousands of RITMs of work.  Our teams were working the RITMs directly without SCTASKS, unless a one-off was needed to be sent to another team.

In a "2.0" version of these forms, we moved our staff to work out of SCTASKs by adding a workflow to the Catalog Items that simply create and assign a default SCTASK to the fulfillment group.  The Flow was created in Flow Designer and is configured to use the "Service Catalog" trigger.  For new RITMS, it's working as expected.

When someone updates an older RITM that was created prior to the Flow being attached to the item we're finding that the new Flow triggers and the SCTASKs are created.  This is an unexpected behavior we didn't know to test for during dev, and is causing a lot of confusion, (eg:  the SCTASK was assigned to the original fulfillment team, and but the RITM had been assigned somewhere else earlier).

Is that expected behavior?  What's the right way to trigger the flow to execute only when the RITM is created and not any time afterward?

I appreciate all the help!

[Geoff_T]

Hey,

The Service Catalog trigger is designed to only trigger when a Catalog Item is requested. I can't see any way your flows are being triggered by an update to an existing RITM. It definitely is not expected behavior.

https://docs.servicenow.com/bundle/quebec-servicenow-platform/page/administer/flow-designer/task/create-sc-flow.html

Are you sure the new flows you see are not from new requests being submitted?

Geoff

[Peter Shearer]

Thanks for responding, Geoff!

It's good to get some confirmation here.  I had read that link and had interpreted it same as you.  That's why I'm scratching my head on this one!

I know for sure that the new workflow is triggering for older RITMs by testing on a few items that were created around March 2021.  They did not have flows before, and now they do - and the new flow structure matches the current flow assigned to that Catalog Item.

To make it stranger, I've not been able to trigger this behavior in our dev environment.  I suspect there's a configuration difference between the two that may be a factor here.

Peter

[Peter Shearer · Accepted solution]

I've figured this one out.  There's a built-in business rule "Start FlowDesigner Flow" that triggers on an RITM when:

• Item is not empty
• Flow Context is empty
• Stage is "request_approved"

When a change is made to an RITM and that criteria is met, it triggers the Flow to start. In our case, most (if not all) of our previous RITMs were created and stayed in "request_approved" state without a Flow run on them.  When we added the new Flows to these items, this business rule started triggering when a change was made/saved to the old RITMs.

Generally, I would think this is a desired behavior - just not if you've violated design principles when setting the system up originally.

I'm fixing this with a date filter (don't execute on older than X) to attrit out the old items, then will remove it at a later time.

Thanks for your input!

Peter

[Geoff_T]

Nice find Peter!