Trigger workflow on record update

[roshanrao]

Hi All,

I have the need to update a business system every time a record is inserted or some of its fields updated.

The integration to this system is using SOAP-based web services - I am using a workflow because the SOAP call is async (MID) and it is easier to build out error handling with workflows.

My workflow is getting triggered properly when a record is inserted. It does not when the record is changed. What are my options to trigger it "after update".

1. I would prefer not to pull my logic into after or async business rules - primarily because I would have to build out components for exception handling.

2. Another option is to have the insert workflow go into a wait state and monitor for updates. Again, this is probably not the most efficient way of doing this, given that the automation lifetime in happy path does not have to be more than a few seconds. Long running workflows would have impacts on the system over a period.

Thoughts?

- Roshan

[Chuck Tomasi]

Hi Roshan,

Does your workflow have a condition defined in the properties? Normally you can get a workflow attached to a record when the record is created. If you add a condition (e.g. state='approval') then the workflow won't be started until the record's fields meet the condition (in this case when the state moves to approval.)

Q: What do the properties on your workflow look like? Please include a screenshot if possible.

[roshanrao]

Hi Chuck,

There are a couple of additional pieces to the overall integration. What described in the OP is the outbound (write) integration to the Business System (SOR), which is SOAP-based. The inbound integration (read) is JDBC/MID using import sets/transforms.

The source record has a field that stores the primary key (SOR ID) of the record from the SOR, which the current "insert" workflow updates once the web service call to the SOR succeeds.

My trigger condition right now is fairly simple: Trigger workflow when SOR ID of the record is empty OR sys_updated_by != "import user (Run as on scheduled import)".

From what you are saying though, my understanding is that I would potentially need to create a separate workflow to monitor updates.

This would be a workflow set to "always run" that gets triggered once the insert into the SOR is complete (SOR ID!=null). It would basically just monitor for changes (Wait activity). Though this will likely work, my concern would be around letting these workflows sit around. Across all the tables that I need to do this, we are talking about 10+ million records. Does this concern you as well?

Thanks

R

[Chuck Tomasi]

Hi Roshan,

Yes, I would be concerned about triggering 10 million records/workflows. It is right of you to be concerned about that.

Is there a way for you to reset the existing records so the workflow will run again based on those conditions (SOR ID is empty or sys_updated_by != import user)? If you reset the sys_updated_by field with something like this:

var rec = new GlideRecord('your_table_name');

rec.addQuery(); // Add the filter to get just the records you want

rec.query();

while (rec.next()) {

        rec.autoSysFields(false); // Don't update the sys_ fields

        rec.setWorfklow(false);   // Don't trigger workflows or business rules

        rec.sys_updated_by = 'Test script';

        rec.update();

}

Of course, try this on one or two records first before looping through hundreds.

Now the sys_updated_field is reset and the next update to the record will trigger the workflow per your conditions.

[roshanrao · Accepted solution]

To close this out.

I ended up adding a field called "Last Committed Update" to my table(s). This is the equivalent of sys_mod_count and its value should be equal to sys_mod_count if the workflow completes. That way I can see records that have gone out of sync (pending workflow completion, or failed).

I was able to kick off workflows on update (restart) by adding a BR that did this:

restartWorkflow: function(current) {

new global.Workflow().restartWorkflow(current);

current.autoSysFields(false);

current.update();

}

I updated the workflow to be "post BR" and updated the triggering BR to have Order >=1000. This graphic is useful in understanding the execution order: https://docs.servicenow.com/bundle/istanbul-servicenow-platform/page/administer/using-workflows/conc...

The one other piece was that workflows had a limited # of restarts because there is a default limit on the number of activities (Max activity count in Workflow Properties). Since these workflows were technical in nature, I did not need to keep the history. So, I was able to get away adding a job to delete inactive workflows.

All in all, I felt like I was driving a square peg into a round hole. If I have to do this again, I will likely not use workflow for this purpose.