Conditions, loops and approvals

Most steps do a piece of work: fetch invoices, draft an email, send it. Control steps do no work of their own. They look at the items passing through and decide which step gets each one next. You find them in the Control group at the bottom of the Nodes panel, and you add and connect them like any other step (see Find your way round the canvas).

app.centrus.ai/app/agents/workflow-builder

Chase overdue invoices

1,240 / 10,000 creditsValidateResetDraft saved

Runs5

SettingsSave and Publish

Weekday mornings

Daily at 09:15 · Mon, Tue, Wed, Thu, Fri

Fetch unpaid invoices

List invoices

Overdue by 1 to 14 days

Keep ALL of 3 rule(s)

Each overdue invoice

For each of incoming items

Over £1,000?

totalInclTax greater than

Check before sending

Approve in panel (wait up to 480 min)

Send chase email

1 action enabled

Send reminder email

1 action enabled

2

3

4

AI builderMap

Ready to publish

1. 1The Control group in the Nodes panel, with all ten control steps.
2. 2A Condition, Over £1,000?, which sends larger invoices one way and the rest another.
3. 3A Loop, Each overdue invoice, which runs the steps after it once for each invoice.
4. 4An Approval, Check before sending, which holds the run until someone approves or rejects.
5. 5Runs, where you start a test, approve waiting runs and see which branch each item took.

The figures follow one agent, Chase overdue invoices, signed in as John Martin. Every weekday at 09:15 it fetches unpaid invoices from BigChange and keeps the ones between 1 and 14 days overdue. For each one, it checks the total. Invoices over £1,000 wait for Sarah Price in accounts to approve a chase email. The rest get a standard reminder straight away. The invoices stay in BigChange throughout; the agent only reads them.

• Condition checks one rule and sends each item down a true or a false path.
• Route checks several rules and sends each item down the first matching path, or every matching path, with a fallback for the rest.
• Resolve Entities matches a loosely written name or address against a list of records and picks the right one.
• Dedupe lets each item through once and holds back any it has seen before, across runs.
• Batch groups items into fixed-size batches, so the next step handles 50 at a time instead of one.
• Backoff pauses the run for a set time before carrying on.
• Loop runs the steps after it once for each item in a list.
• Approval pauses the run until a person approves or rejects, in the Runs panel or by email.
• Stop ends a path on purpose and records why.
• On run error runs its own steps if the run fails, so someone hears about it.

For the steps outside this group, such as Filter, Transform and the integrations, see Steps an agent can use.

A step with more than one exit has more than one handle on its right edge. Each handle is a separate output, and you connect each one to the step that should handle those items. Hover over a handle to see its name.

• Items only travel along exits you have connected. If an exit has items but no connection, those items stop there and nothing reports it.
• A branch that receives no items does not run. Its steps do not appear in the run, and they cost nothing.
• A Condition with neither exit connected shows the warning This condition has no true/false branch connected. when you validate. Connecting just one exit clears the warning, so check the other exit is meant to be empty.

You can connect two branches into the same step. Centrus does not wait for both and merge them. The step runs once for each branch that delivers items, as a separate visit each time.

Over £1,000?

totalInclTax greater than

Check before sending

Approve in panel (wait up to 480 min)

Send chase email

1 action enabled

TrueFalseApproved

Runs once for each branch that reaches it

Say four invoices arrive at once. One is over £1,000 and is approved; three are under. Send chase email runs twice: once with the single approved invoice and once with the three smaller ones. Both visits appear in the run, each with its own row. A later step that refers to Send chase email with {{ steps.<id>.json.field }} reads its most recent visit.

Inside a Loop, which hands over one item at a time, only one branch has an item on each pass, so a shared step runs once per pass. If you need one step to run after both branches have finished, run them inside a Loop and connect the work that follows to the Loop's Done exit.

Condition checks one rule against each item. Items that pass go out of the true exit; the rest go out of false. In the example, it sends invoices over £1,000 for approval and the others straight to a reminder.

The field path can be a plain field name, a dotted path such as site.postcode, or an expression in double braces, such as {{ item.json.job.CustomFields | customField('Caption') }}. The Value box takes expressions too, so you can compare against a field from an earlier step.

• Text: equals, does not equal, contains, does not contain, starts with, ends with, is empty and is not empty.
• Numbers: greater than, less than, greater than or equal and less than or equal.
• Dates: date before, date after, date on or before, date on or after, within last N days, not within last N days, within next N days, not within next N days, in N days (calendar day; 0 = today), is today, is this week and is this month.

equals and does not equal compare exactly, so Urgent does not equal urgent. contains, starts with and ends with ignore case.

• A new Condition starts with no field and the operator is not empty, so every item goes down false until you fill it in. Validation does not flag a Condition left like this.
• The canvas card shows the field and operator, such as totalInclTax greater than, but not the value. Open the step to check the value.
• Use batch mode when the decision depends on the run as a whole rather than each item, such as whether an earlier count is above zero.

Route is a Condition with more than two answers. You add a route for each case, each with its own rule, and every route gets its own exit. Items that match no route leave through the fallback exit. Here, reactive jobs from BigChange are sorted by priority: emergencies text Dylan Hughes, the on-call engineer, urgent jobs email the planners, and everything else goes on a daily list.

By priority

First of 2 routes + fallback

Emergency: text on-call

To 07700 900123

Urgent: email the planners

1 action enabled

Everything else: daily list

Collect into items

4

1. 1Match mode. First matching route only sends each item down the first route it matches, in the order listed. All matching routes sends a copy down every route it matches.
2. 2Add route adds another route and another exit.
3. 3A route card: its id, which you cannot change, its label, which names the exit, and its rule.
4. 4Route's exits on the canvas: one per route in order, then the fallback at the bottom.

Each route has a Rule mode. Field/operator rule uses a Field path, an Operator and a Compare value, with the same operators as Condition. Boolean expression takes an Expression that works out to true or false, such as {{ item.json.priority }} === 'high'.

• The canvas draws exits for the first eight routes only. If you add a ninth, it has no exit to connect, so keep to eight or fewer.
• Validation messages name a route by its id rather than its label. The first route has the id a; routes you add get a long generated id, so match the id against the route cards.
• Items that match nothing and have no fallback connection stop at the Route.

Loop takes a list and runs the steps on its loop exit once per item. When the last item has been through, it sends everything that came back out of its done exit in one go. In the example, each overdue invoice is checked, approved if needed and emailed, then the Loop moves on to the next.

Each overdue invoice

For each of incoming items

1

2

Over £1,000?

totalInclTax greater than

Send chase email

1 action enabled

Email the summary

1 action enabled

Back to the Loop

1. 1The loop exit. Connect the first step that should run for each item.
2. 2The done exit. It fires once, after every item, with all the items that came back.

The loop body is the chain of steps between the two exits. To build one:

1. 1Connect the list into the Loop's left handle.
2. 2Connect the loop exit to the first step of the body.
3. 3Connect the last step of every path in the body back into the Loop's left handle. That return tells the Loop the item is finished and it can start the next.
4. 4Connect whatever should happen once at the end, such as a summary email, to the done exit.

Inside the loop, {{ item.json.<field> }} refers to the current item, such as {{ item.json.reference }} for the invoice reference.

A third option, Ingest or merge dataset (batched rows), loops over a large list staged by an Ingest or Merge datasets step. You give it a Dataset ID expression and it hands over rows in batches, 100 at a time unless you change Batch size.

If the list is longer than Max iterations, the run fails rather than stopping at the cap. If a list could ever exceed 100, raise the cap before you publish.

• Every exit in the body should lead back to the Loop, including the false branch of a Condition and the rejected branch of an Approval. If a path ends without returning, the Loop still moves on, but that item is left out of what done sends.
• done fires even when the list is empty, so a summary step after it runs every time. Put a Condition after done if the summary should only go out when there is something in it.
• Each pass appears in the run as a Loop row reading Loop item 1/4, Loop item 2/4 and so on, followed by the steps for that item.
• Only a Loop can have steps connected back into it. Connecting a step back to any other earlier step is reported as Workflow graphs must be acyclic (except a loop body returning to its Loop node).

If you forget the return connection, Validate warns you:

Each overdue invoice

For each of incoming items

Over £1,000?

totalInclTax greater than

Send chase email

1 action enabled

1 warning

Validation

Connect the last node of the loop body back into this Loop node so iteration can advance.

Click to focus this node on the canvas

Approval pauses the run and waits for someone to decide. Approve, and the items carry on from the Approved exit. Reject, and they carry on from the Rejected exit, so the run continues either way; connect Rejected to whatever should happen instead, or back into the Loop. In the example, Sarah Price approves each chase for an invoice over £1,000 before it goes out.

A decision has to arrive within 8 hours of the run starting. A run can last 8 hours at most, and the time spent waiting for an approval counts. If the decision or the timeout comes later than 8 hours after the run started, the run fails instead of carrying on. Set How long to wait for approval to 8 hours or less, and less again if steps before the Approval take a while. The longer options in the list do not work for this reason.

For any step that sends, pays or changes something, choose Treat as rejected and continue. With the default, an approver who is away means the chase email goes out anyway once the wait runs out.

To decide in the Runs panel, open Runs from the toolbar and select the waiting run. Its status reads Awaiting approval, and a box above its steps reads This run is awaiting approval.

• You need Edit access to the agent to approve or reject. With View access, the box reads You have view-only access to this workflow, so you can't approve or reject this run. See Share an agent.
• Inside a Loop, each pass that reaches the Approval waits on its own. Four invoices over £1,000 mean four separate decisions, one after another, in the same run.
• After you reject, a message reads Rejected, stopping run. The run does not stop: it carries on from the Rejected exit.
• Centrus does not notify anyone that a run is waiting. Check the Runs panel, or use email approval so the approver gets a message.
• A waiting run counts towards your limit of 10 runs at once.

With By email reply, the Approval emails the approver from a connected Outlook or Gmail mailbox and waits for them to reply APPROVE or REJECT. The approver does not need a Centrus login.

Send via picks Outlook or Gmail, and uses the account connected on that integration elsewhere in the agent. The subject and Message to the approver take expressions, so you can include the invoice reference and customer. Centrus adds the reply instructions and the reference line below your message.

• Centrus checks the mailbox for replies every 2 minutes, so a decision can take a couple of minutes to register.
• It reads the 25 most recent messages each time. On a busy mailbox, a reply can drop out of that window before it is read, so send approvals from a mailbox that does not get much else.
• The reply must come from the approver's address and keep the reference in the subject. A reply that is neither a clear approval nor a clear rejection is ignored, and the run keeps waiting.
• You can still approve or reject an email approval in the Runs panel.
• In a dry run, no email is sent. The Approval waits for a decision in the Runs panel instead.

Connecting a mailbox is covered in Microsoft Outlook in Agent Builder and Gmail in Agent Builder.

Dedupe remembers a key for every item it lets through and holds back any item whose key it has seen before, in this run or an earlier one. It suits agents that run often over overlapping data. Here, an agent runs every hour, fetches jobs completed today and sends a satisfaction survey. Without Dedupe, a job completed at 10:00 would be surveyed again at 11:00, 12:00 and every hour after.

Dedupe has three exits: unseen items leave by the main exit, items seen before leave by seen, and items rejected for a missing key leave by reject. Connect seen only if you want to do something with repeats.

• Key expression (optional) builds the key from an expression and overrides the field paths. Composite key fields (optional) builds it from several fields, joined with the Key delimiter.
• Normalisation tidies keys before comparing: No normalisation, Trim whitespace or Lowercase + trim.
• Scope field (optional) keeps separate lists per value of a field, such as one per mailbox or per site.
• Dedupe within current run also catches repeats within a single run.
• Persist mode offers Persist every new key, Persist only when field equals values, which remembers a key only when a field you name holds one of the values you list, and Do not persist (run-local only).
• Keys are saved when the run succeeds or pauses for an approval. If the run fails, they are not saved, so the same items come through again on the next run.

Resolve Entities is for items that name something loosely, such as a tenant's email that says Riverside Hse, flat 12, when you need the exact site record. Each item carries a list of candidate records, from an earlier lookup, and Resolve Entities scores each candidate against your rules and picks the best.

Items leave by one of three exits: resolved when one candidate wins, needs_review when the match is uncertain, and failed when the item cannot be resolved. A useful pattern is to send needs_review to an email or a list for a person to sort out.

• Match strategy is Score candidates or Single candidate only. Minimum score is the score a candidate needs to count as a match.
• On no match, On multiple matches and On dependency missing each choose Needs review, Failed, or a third option: Skip entity for no match and dependencies, Pick best for multiple matches.
• Prefer field (tie-break, optional) and Prefer direction break ties, such as the most recently updated record.
• Pick field (optional) writes just one field of the winner, such as its id, instead of the whole record.
• Transforms tidy both sides before comparing: None, Trim, Lowercase + trim, Digits only, Alphanumeric only and UK postcode.
• Dependencies (optional) resolves one entity using another already resolved, such as finding the contact once the site is known. Add each with Add entity.

Batch groups items so the next step handles several at once. If an agent writes 240 completed jobs to an Excel workbook, groups of 50 mean five writes instead of 240. Each batch leaves the batch exit as one item holding a list, and once every batch has gone, one summary item leaves the done exit.

Backoff pauses the run before passing its items on. It is for spacing out calls to a system that limits how often you can contact it.

• Batch's first menu chooses Batch incoming items or Batch values from a field. With the second, give the Item value field that holds the list, and turn on Flatten arrays from field values to merge lists from several items.
• The box beside it is the output key, the name of the list in each batch. It is batch unless you change it.
• Batch size is 10 unless you change it. Max batches (optional) caps the number of batches; leave it on Unlimited to batch everything.
• The switches add extra detail to each batch: the item's position, its file attachments, its internal metadata, a link back to the source item, and the batch number and counts.
• Backoff's Delay (ms) is in milliseconds, so 1000 is one second. Jitter (ms) adds a random amount up to that figure, and Max delay (ms) caps the total, 300000 (5 minutes) unless you change it.

A paused run is picked up by a check that runs every 5 minutes. A Backoff of one second can hold the run for up to 5 minutes, and inside a Loop that wait comes on every pass. Use Backoff for spacing that is measured in minutes, not seconds, and keep it out of loops that need to finish quickly.

Stop ends the path it sits on and records a note of why. It has no exits. Here it sits on the empty exit of Fetch unpaid invoices, so a day with no unpaid invoices shows a clear note in the run rather than a short list of steps.

Fetch unpaid invoices

List invoices

Overdue by 1 to 14 days

Keep ALL of 3 rule(s)

Nothing to chase

Ends the run

Ends this path only

• Summary is the note the run records at this step.
• Stop ends only its own path. Other branches carry on, and a Loop moves on to its next item.
• A run that reaches a Stop still finishes as Success. The canvas card says Ends the run, but other branches keep going.

A step fails when, for example, BigChange is unreachable or a mailbox has been disconnected. Unless you change it, a failed step stops the whole run and the run shows as Failed. You can change that for each step, and you can add an On run error step to tell someone.

Weekday mornings

Daily at 09:15 · Mon, Tue, Wed, Thu, Fri

Fetch unpaid invoices

List invoices

Send the daily summary

1 action enabled

1

Text Sarah Price

To 07700 900456

If the run fails

Runs only if this run errors

Email the office

1 action enabled

2

1. 1The error exit, which appears on the bottom of a step set to Continue via error branch. If that step fails, its items leave here.
2. 2On run error, off the main path, which runs if the run fails.

Every step has Advanced: error & retry at the foot of its Details panel:

Add On run error anywhere on the canvas without connecting anything into it; it starts by itself when a step's failure stops the run. Connect it to an email or a text so someone hears. Its items carry the error message as error, the id of the step that failed as failedNodeId, and the run's id as runId, so you can put them in the message.

• An agent can have one On run error.
• The run still shows as Failed after On run error has done its job.
• Keep the steps after it simple. An Approval or a Backoff on that path cannot pause, and validation warns if you add an Approval there.

Control steps are cheap, but inside a Loop they run once per pass, so the count adds up. Each run costs 1 credit to start. Triggers are free. Each integration call, such as sending an email, costs 1 credit. Logic steps, including Condition, Route, Dedupe, Batch, Resolve Entities and Approval, cost 0.1 credit each time they run. The Loop itself is free.

• A branch that receives no items costs nothing, because it does not run.
• Approval and Backoff are charged when they finish, not when they start waiting. Picking a run back up after a wait does not charge another 1 credit.
• A dry run charges for starting the run but skips the per-step charges.

Your allowance and the full price list are in Automation credits and usage limits.

Open Runs from the toolbar and click Run now to run the agent by hand. A dry run reads real data but only simulates sending, so it is a safe way to see which way each item goes. The options are covered in Test an agent before it goes live.

• Click a step to expand it and see its Output counts and the data it passed on.
• Steps on a branch that received nothing do not appear at all. If a step you expected is missing, expand the control step before it and check which exit got the items.
• To test both sides of a Condition, run the agent on data that has an item for each side, or change the value for one test and change it back.

Everything else the Runs panel shows is covered in Read the Runs panel.

• Approvals happen in the Runs panel or by email. There is no way to approve from chat, WhatsApp or Teams.
• Email approval goes to a single address. To give two people the option, use a shared mailbox address.
• There is no step that waits for several branches to finish and then joins them. Use a Loop and its done exit instead.
• The canvas does not show which branch a run took. Check the run's steps in the Runs panel.