Running a workflow when a record is deleted

[jelmer]

When deleting a GlideRecord, sometimes you might want to start a workflow that uses one or two fields from the record and runs after deletion. However, if you force a Business Rule (method: delete) to start a workflow it will cancel.

But what if you need a workflow to do something at deletion of a certain record? Think about workflows that call external APIs and store an ID in a GlideRecord. Now this workflow should be able to call a remote system to delete an object in that other system with the ID in the GlideRecord. How to do this without getting the workflow cancelled?

The current solution is to start the workflow with no reference to the current record, like below:

// Business Rule: before delete

(function executeRule(current, previous /*null when async*/) {

      var workflow_params = {'someid': current.some_id.toString()};

      var workflow_record = new GlideRecord ...

      if (!workflow_record) {

              gs.info('workflow xyz not found!');

              return;

      }

      var wkf = new Workflow();

      wkf.startFlow(workflow_record.sys_id, null, 'delete', workflow_params);

})(current, previous);

Is this a more idiomatic way to do this in ServiceNow? Any other alternative solutions?

[Brad Tilton]

What exactly are you needing to do on delete? I think if I had to run a workflow on the deletion of a record, I would create a new table, then create a new record in that table when a record in the original table gets deleted. Honestly, I think if a record is important enough to have a workflow run against, I would probably just deactivate it instead of deleting.

[jelmer]

We do DevOps using ServiceNow. So the CMDB is leading when it comes to how infrastructure should be configured. So we have the provisioning of a monitoring system arranged so that you can enable a monitoring feature on a CMDB CI record and it will be monitored in the backend.

The 'monitoring provision workflow' will store the ID of the monitoring system's reference to this CMDB CI in the GlideRecord. Propagating updates to the IP address or other settings are done through other workflows that need this host ID to call the monitoring system's API on the backend. The retirement or disabling of this feature runs a workflow to disable the host in monitoring without deleting it. This is normal behavior. But sometimes you want to delete the host from monitoring alltogether. And you need the ID to call the external API.