> ## Documentation Index > Fetch the complete documentation index at: https://docs.insight.nobly.dk/llms.txt > Use this file to discover all available pages before exploring further. # Workflow trigger or script hook > Both a workflow event trigger and an event_hook script react to document events — which one to configure, what changes if you pick the other, and how they behave side by side. ## 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 | | Workflow event trigger | `event_hook` script | | - | - | - | | What you configure | A definition in the designer: scope, filter, nodes, actions | A published Python script, bound to a document type and event | | Who it runs as | The workflow's service identity, and tasks can be given to people | A configured service account, in the background | | Asking a person | Built in — tasks, and [interaction rules](/workflows/interaction-rules) before a new document is stored | Not available; a hook runs after the fact and returns only an acknowledgement | | Where you see what happened | Instance history and the Tasks inbox | Script execution logs | | Changing it | Edit and publish a new version in the designer | Edit the script and publish a new version; the existing binding runs the published version, so it needs no change | | Best for | Multi-step processes, human decisions, keyword and Caseflow updates | Calling an external system, custom validation, anything needing real code | 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](/scripts/bindings-and-events#design-for-background-processing). ## 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](/scripts/bindings-and-events#remove-a-binding) does not delete the script. ## Where to read next Understand document ingestion, mapping, workflow definitions, and processing states in Nobly ContentFlow. Configure an `event_hook` binding, and what a background script may assume about identity and delivery. The `Script.Run` action: its parameters, the identity it uses, and how a script's output becomes an instance variable. Trigger types per anchor, scope, and the gates an event passes before an instance starts.