Flows and Business Rules don't trigger/fire when an API call creates a record on a table.

Adrian Weber1
Tera Contributor

I have a Flow with a trigger setting of "Record Created or Updated" on the em_event table. 
The flow triggers perfectly when testing and I manually create a new record using the "New" UI Action.   However, once this goes to Production, an API call is going to be creating/updating those records.  We are simulating this in our UAT environment by using POSTMAN to drop a "payload" that creates the new record on the table. 

The Flow doesn't trigger in this manner, however.   AI research indicated that the "injection method" the API is using is bypassing the CRUD functions that Flow triggers use to recognize activity.  It was suggested that I use a Business Rule instead, and call the Flow using that Business Rule.  
Unfortunately, even with that setup, I'm still seeing the same behavior..  The business rule isn't getting triggered any more than the Flow did... Again, MANUALLY creating the new entries triggers the business rule which calls the flow (now a sub-flow) and everything works... but I need to have the flow/business rule trigger when the API creates/updates the records. 
Has anyone else run into something like this?

Thanks in advance for any help you can provide. 

5 REPLIES 5

Vikram Reddy
Tera Guru

Hi @Adrian Weber1,

 

This lines up with a documented mechanism rather than something odd about your Flow. A "Created/Updated" trigger only fires when the insert writes a row into sys_flow_context, and any gr.setWorkflow(false) call earlier in that same transaction skips that write, along with skipping Business Rules on the same operation. It's worth knowing that ServiceNow explicitly discourages running Business Rules on em_event for performance reasons, so it wouldn't surprise me if whatever handles your Postman payload, an inbound script or an earlier before-insert rule, is quieting the insert on purpose.

Before digging further, check:

  • setWorkflow(false) anywhere in the em_event insert path, including any stock event-processing script
  • the trigger_engine.ignore.set_workflow system property, which controls whether that call also blocks Flow trigger writes
  • the order your new Business Rule runs at relative to whatever is doing the insert
  • whether the payload is actually landing in em_event itself and not a staging or extended variant of it

trigger_engine.ignore.set_workflow's default behavior has shifted across releases, so confirm what your instance actually does before assuming it.

 

Thank you,
Vikram Karety
Octigo Solutions INC