Automations

An automation in BNDRY is a runnable unit of compliance work — a job the platform executes on your behalf so that checks, orchestrations, and downstream integrations don't sit on a person's to-do list. Automations live alongside workspaces and forms in your tenant configuration, and you can see what's available to run from the platform's Automations area.

An automation is the definition; an automation execution is the running instance. When you run an automation, BNDRY creates an execution and tracks its state from start to finish. Executions can take longer than a single request to complete and may pause part-way through to request input from a human.

Why automations exist

Compliance work is repetitive, sequenced, and easy to get wrong when it's done by hand. Screening a new customer, recalculating a risk rating after a change of circumstances, verifying an identity document, kicking off a periodic review — each of these is a series of steps that has to happen the same way every time, with a defensible record of what ran and why.

Automations exist to operationalise those workflows. They run the checks, orchestrate the sequence, and feed the outcomes into the rest of the platform — into the entity's risk rating, into tags, into the audit trail. Because each execution is tracked as its own resource with a clear state and timestamps, you also get the answer to the question every auditor eventually asks: when did this run, what did it do, and what was the outcome.

Key properties and sub-types

BNDRY automations come in two shapes, distinguished by how much work they take on:

• Task automations are single-purpose jobs. One automation, one outcome — for example, a screening check, a risk rating recalculation, or a verification call against a single data source.
• Process automations chain task automations together into an end-to-end workflow. A new customer onboarding process automation, for instance, typically runs identity verification, then screening, then a risk rating, then surfaces a final review form — all under a single execution.

Regardless of shape, every execution carries the same core properties:

• State — the current status. An execution is active while it's running, requires input when it's paused waiting for a human to fill in a form, succeeded or failed once it finishes, or cancelled if it was stopped intentionally.
• Input parameters — the values supplied when the automation was run. Each automation publishes an input schema so the caller knows what to provide.
• Forms — the resource names of any forms the execution is currently waiting on. This is how an automation hands off to a person mid-flight.
• Start time and end time — when the execution began and when it finished, used by both the platform and the audit trail.
• Error — populated only when the execution finished in a failed or cancelled state, with the reason it stopped.

Automations need clear ownership and failure handling. If a job fails, the execution's error field captures what went wrong, and your operational setup decides who gets notified and what happens next.

How automations relate

Automations are the "doing" layer of the platform. They consume the rules expressed by policy — a screening automation runs because policy says new customers must be screened; a risk-rating automation runs because policy defines how risk is calculated — and they produce outcomes that show up elsewhere: a risk rating on an entity, a tag applied to an individual or company, an event emitted to your downstream systems.

When an automation needs information it doesn't have, it pauses and surfaces a form. When it finishes, the result is recorded against the individual, company, or other resource it was acting on, and the execution itself remains queryable as part of that resource's history.