Workflow trigger or script hook

​

The short answer

Start with a workflow event trigger. Configure a workflow definition, subscribe it to the document event, and narrow it with scope and a filter. Reach for an event_hook script when the reaction needs code that configuration cannot express. You do not have to choose one permanently. A workflow can run a script as one of its steps with the Script.Run action, so the declarative path stays in charge while the code does the part that needs code.

​

What each one is good at

Prefer a workflow when the outcome is a process someone may need to see, audit, or intervene in. Prefer a script when the outcome is a call into another system.

​

They both fire

A document event reaches both extension points independently. A document type with an event_hook binding and a workflow trigger runs both for the same upload, in no guaranteed order. That is not a conflict to fix — it is worth knowing before you add a trigger to a document type that already has hooks, or the reverse. One asymmetry matters when the two meet:

• A write made by a workflow starts no workflow at all. A workflow that updates its own document does not re-trigger itself, and a Caseflow object it creates does not fire Caseflow triggers.
• A write made by a script is an ordinary write, even when a workflow ran the script. If the script updates a document of a type a workflow subscribes to, that workflow starts for that document, and that includes the workflow that ran the script. For another document it starts as for any other event: when the trigger’s filter matches and that document has no running instance of the workflow. For the document it is working on, the write’s event starts nothing while its instance is still running, because only one instance of a workflow runs per document — but if the event is handled after that instance has finished, the workflow starts again.

So when a Script.Run step writes to the document the workflow is working on, give the workflow’s trigger a filter precise enough that the script’s own write does not match it. The same caution applies to a hook that updates the documents it subscribes to, as described in bindings and event hooks.

​

Moving an existing hook into a workflow

Script.Run only runs workflow_action scripts, so an event_hook script is not offered as it stands. Publish the code again as a workflow_action script, and expect two things to change:

• Where its input comes from. A hook receives the event — event type and ID, timestamp, entity, triggering username, payload. A workflow script receives the ID of the workflow’s document or Caseflow object, unless the step names another, and whatever the step’s Input passes in, built from the workflow’s own references.
• What the event’s own detail can tell it. The event fields a hook reads are not part of a workflow’s variables. Pass what the script needs explicitly from the step’s input.

Keep the original hook bound until the workflow version that replaces it is published and verified, then remove the binding. Removing a binding does not delete the script.

​

Where to read next