Your systems detect it. Your team gets guided work.
Your systems already know when something needs doing: a shipment arrives, a deal closes, a batch fails a check. External Triggers give them a uniform ingest API to say so. A trigger rule turns the event into a run, the run waits in a claimable team queue, and a worker executes it step by step with the external data already in place. What actually happened, deviations included, flows back to your systems. Detect, guide the human work, observe reality, improve.
Capabilities
What you can do
One uniform ingest API
Every source, from SAP to a Google Apps Script, posts events the same way. Per-source tokens, optional HMAC signing, idempotency keys and a test mode keep it safe to build against.
Trigger rules with payload filters
Match on the event name and filter on payload fields, so only the right events become runs. Dedupe windows stop a chatty system from creating the same run twice.
Visual field mapping
Send a sample payload, or generate a suggested payload from the workflow itself and copy it as the contract. OpsBrain proposes the mappings; you approve them.
A claimable team queue
Triggered runs wait as claimable work with priority and live wait time. Workers claim and release, managers reassign, and run names come from templates like {{shipment_id}}.
Claim SLAs with escalation
Give urgent runs a claim SLA. If nobody picks the work up in time, the right people are notified automatically. The queue cannot silently stall.
Deviations captured, loop closed
Prefilled fields can be editable, read-only or confirm-required. When a worker corrects a value, the change is recorded as a deviation and included in the run.completed event back to your systems.
In practice
How teams use it
A shipment arrives before anyone types a thing
Your WMS posts shipment.arrived with the container ID and pallet count. A trigger rule matches, creates a receiving run named after the shipment, and it appears in the dock team's queue at high priority. Whoever claims it opens a guided checklist with the carrier, the PO and the expected count already filled in.
The ERP said 12 pallets. The worker counted 11.
Prefilled data is not blind trust. The expected count arrives as a confirm-required field, the worker corrects it to 11, and OpsBrain records the change as a deviation. Your ERP receives run.completed with both values, so the discrepancy is in your system of record minutes after it happened, not at month end.
A deal closes and onboarding starts itself
closed-won in your CRM sends an event through your iPaaS. OpsBrain creates a customer onboarding run with the account name in the title and the plan details prefilled. The CS team claims it from the queue, and every step from kickoff to go-live is tracked from day one.
A quality hold that refuses to be ignored
Your lab system flags a batch. The trigger creates an urgent containment run with a 15 minute claim SLA. If nobody claims it in time, the shift lead is escalated automatically. The whole timeline, from event received to run completed, sits in the inbound activity log.
Setup
How it works
Register a source
Create a source per external system. Each gets its own token, optional HMAC signing and a test mode for safe experiments.
Define the contract
Send a real sample payload, or generate a suggested payload from the workflow and hand it to the other team as the contract.
Map fields and set behavior
Accept the suggested mappings, mark each field editable, read-only or confirm-required, and set run name templates, priority, dedupe and the claim SLA.
Go live and watch
Fire the in-app test event panel, watch runs appear in the queue, and follow every inbound event in the activity log, with replay when you need it.
See External Triggers working with your operation.
Book a walkthrough and we will set it up against one of your real workflows, or start on your own in minutes.