An automation builder, inside your compliance platform.
Workflows let you automate a business process without writing code, before, during or after verification. Choose what starts it, assemble the steps you need on a canvas, and get a structured result on every run. A detailed log of each step lets you understand, correct and replay a workflow at any time.
A general-purpose automation builder that happens to live in Ceertia.
A workflow can run before a check, after a check, or with no check involved at all. Verification is one possible trigger and one possible node among others, never a mandatory step.
Nothing in the builder assumes a file exists. A file is one possible context, available depending on the trigger, and absent in most scheduled or externally called workflows.
"Run a check" and "AI analysis" sit in the catalogue next to HTTP requests and emails. Neither is mandatory nor privileged on the canvas.
A workflow never starts or stops without a trace. Every run leaves a log you can open, and irreversible actions are identifiable on the canvas.
Four families, treated as equals.
A workflow has one trigger. Each family brings its own context and its own input payload, and none of them is the normal case with the others as variants.
01Platform events
Any event Ceertia produces starts the workflow: a file created, updated or closed, a document added, an extraction finished, a check completed, a verdict non-compliant, a deadline reached.
- A searchable, categorised catalogue that keeps growing
- Filters, so it fires only for a given file type, use case, client or verdict
02Time
The workflow runs on a clock: a recurring schedule, a one-off run at a given date and time, or a delay relative to an event, three days after a file closes or the day before a deadline.
- Hourly, daily, weekly, monthly, or an advanced expression
- Explicit time zone, and a declared behaviour for missed runs
03Incoming calls
Your own systems call the workflow in real time, through its authenticated endpoint, an inbound webhook with signature verification, or an email received on a dedicated address.
- The call can be answered synchronously: the output is the HTTP response
- Which makes the workflow an API you built without code
04Manual
Someone starts it on purpose: on demand from the workflow list, as an action launched from a file or from a question, or called by another workflow as a sub-flow.
- Right for testing a change before leaving it to run on its own
- What the user enters becomes the payload
Expose a workflow behind a URL.
A workflow triggered by its endpoint can answer synchronously: your external client calls the URL, the workflow runs, and its structured output is the HTTP response. The workflow is an API you built without code.
The interface shows the URL, the token, the expected input format and the output format returned, so the contract is explicit on both sides.
Before, after, or not at all.
The compliance engine takes three positions in a workflow, and none of them is more natural than the others.
Pull the documents of a file from a CRM API, attach them, then start the check.
A non-compliant verdict sends an email with the reasons, creates an internal task and pushes a row into the CRM.
Client follow-ups, a nightly synchronisation, a weekly report, a process exposed as an API. The engine never comes into play.
Every step is a node. Seven categories.
The palette is filterable and categorised, and stays readable when the catalogue triples in size.
What a workflow can see depends on what started it.
Available data varies by trigger, and you need to understand that while you build, not when your workflow fails.
At each node, the variables actually available at that point are listed, and a picker inserts them so you never type them by hand. A variable referenced but unavailable is flagged while you build, not at run time.
Build it by hand, visually.
Drag nodes from the palette, or click to insert one after the selected step. Connect them and label each link, so the logic of the workflow reads at a glance.
Horizontal or vertical layout, automatic repositioning, fit to screen. Filter the palette when it grows.
Select a node or a link to change its settings, or open the JSON definition to see exactly what will run.
The builder saves the definition the backend executor runs. No gap between the workflow you designed and the one that executes.
Every run is readable, and repeatable.
Test with an input you type, or reuse the input of a past run, instead of rerunning everything.
Repeat a run identically, or restart it from the step that failed.
Test runs are marked as such, and irreversible actions are blocked unless you explicitly allow them.
Filter runs by outcome and duration, then open one run node by node.
Automations fail. Yours will say so.
Every behaviour under stress is declared, visible in the interface, and never silent.
A policy per node: number of attempts, interval, and when to give up.
A timeout per node and a maximum duration per workflow, both visible.
An idempotency key on incoming triggers, so a repeated call does not produce the same effect twice.
A declared behaviour when the workflow is already running: run in parallel, queue, or skip.
Frequency limits on incoming endpoints and on outbound calls.
Tokens and keys stored separately, masked in logs and in exports.
A maximum sub-flow depth, with loop detection and the path that looped.
A ceiling on runs, with an alert before anything is blocked.
Four workflows, four starting points.
Trigger: check completed, filtered on non-compliant verdicts. The workflow composes an email with the reasons, sends it, creates a follow-up task and pushes a row into the CRM. If the CRM is unreachable, the failure path notifies the team and the run stays replayable.
Trigger: inbound webhook from the client’s CRM when a quote is signed. The workflow creates the file, fetches the documents over HTTP, waits for extraction to finish, then starts the check. No file exists at the start: the workflow creates it.
Trigger: weekly schedule, Monday at 07:00. The workflow queries the week’s data, aggregates volumes by client, generates a document and emails it. The compliance engine never comes into play.
Trigger: an HTTP call on the workflow’s endpoint, with an identifier in the body. The workflow queries an external registry, normalises the result and returns it synchronously. The external client consumes the workflow as a service.
A workflow is an object you own.
Each workflow can be activated or deactivated, and keeps the history of what changed.
A file or a question is an execution context. The same workflow runs across many of them.
The definition is readable, exportable and importable, to move a workflow or reuse a process.
The list shows the last run and its outcome, the recent failure rate, and workflows that never ran.
Common questions, straight answers.
Do I need a file for a workflow to run?+
Can a workflow run without any compliance check?+
Can an external system call a workflow?+
What happens when a step fails?+
Build the automation on the canvas, test it on a real input, activate it. What you designed is what runs, and every run stays readable afterwards.
Bring the process you repeat every week.
In a 30-minute demo we build it on the canvas with you, run it on a real input, and read the log together.