Automations
Overview
Automations are rule sets that react to events: when X happens, do Y — possibly only after a delay, and only if further conditions hold.
Worth knowing: there is exactly one rule engine in the entire system, and this is it. No module brings a second one. What you learn here therefore applies everywhere — and what you set up here can touch anything you are entitled to.
Core tasks
Survey what exists. The list shows name, trigger, number of steps, last run and whether the automation is active. Grouping is by origin:
| Origin | Meaning |
|---|---|
| System | shipped as part of the standard |
| Plugin | contributed by an installed module |
| Custom | created by you or your colleagues |
Create from a template. From template opens the gallery. A template creates a new automation that is switched off to begin with — you adjust it and then arm it deliberately. That is intentional: a rule that starts running the moment it comes into being is hard to keep track of.
Pick recipients, assignees and other records. Fields that point to a record — the recipient of a notification, the assignee of a task, a project, customer, ticket category or page — offer two ways, neither of them typed: From the trigger takes a value from the event, for example the assignee of the ticket that set the automation off; Fixed choice searches for a specific record in the list. An older, hand-written expression stays as Expression and can still be edited.
Do a dry run. The dry run shows what would happen without doing it. This is the right move before every activation — particularly for automations that send messages.
Repeat steps for every entry of a list. Loop adds a step that runs the following steps (shown indented) once per entry of a list — for example per person mentioned in a comment. The list is a field of the trigger ({{ mentionedUserIds }}), the result of an earlier step ({{ step10.rows }}) or an enumeration such as "a@x.com, b@x.com". Inside the loop {{ loop.item }}, {{ loop.number }} and {{ loop.count }} are available, for entries with fields also {{ loop.item.<field> }}. Every iteration has its own state: what a step finds in the first iteration is not visible to the second. A wait inside the loop pauses the run and resumes it in the right iteration; the log names the iteration of every line.
Set the status of a work item. The Set field step with the field statusId and a status key as value sets the status of the triggering work item — for example a ticket from Waiting for customer back to Open as soon as the customer replies. The status goes the same way as a manual change: for tickets the SLA clock pauses or resumes, solved records the resolution time and the satisfaction survey follows; for tasks only an active key from the task status catalogue is accepted. An unknown key leaves the work item unchanged and shows up as an error in the run log. The change appears in the work item's history, marked as triggered by an automation.
React to an email being opened or clicked. The triggers Mail opened (MailOpened) and Link in an email clicked (MailLinkClicked) apply to emails sent with open and click tracking — for example from a deal or a lead. Conditions and placeholders can use the recipient (recipient), the reference (subjectType, subjectId), the brand (brandId) and, for a click, the clicked address (url). firstOpen and firstClick are only true the first time: with the condition firstClick equals true a follow-up task runs exactly once, even if the recipient opens the link five times. Example: url contains "prices" creates a task for sales as soon as someone opens the price list.
React to an assignment. The trigger Work item assigned (WorkItemAssigned) fires as soon as a task or ticket is assigned to somebody — on creation with an assignee as well as on a reassignment, whether by hand, through ticket assignment, from a template or by another automation. Merely removing an assignee is not an assignment. Fields: assigneeUserId (the new assignee), previousAssigneeUserId (the previous one, if replaced), the lists assigneeIds, addedAssigneeIds and previousAssigneeIds, plus kind (task or ticket), brandId and actorUserId (who assigned; empty for system and automation). For outgoing webhooks the event is called workitem.assigned.
React to delivery feedback. The trigger Delivery feedback received (OutboundDeliveryReported) fires as soon as a delivery service reports an outgoing message as delivered or bounced — see Communication. Fields: outcome (delivered or bounced), detail (the reason, such as smtp:550 …), recipient, channel, subjectType, subjectId, mailTypeKey. Example: outcome equals bounced and mailTypeKey equals invoice creates a task "Invoice undeliverable" on the customer.
React to signals from the integration hub. A flow reports a name and payload with the block Signal to automation; the trigger Signal from the integration hub (ConnectSignalEmitted) picks it up. Fields: signal, flowKey, runUlid, brandId, chain (step of the chain), testRun (true for a test run) and the payload as payload.<field>. The condition signal equals pricelist_imported selects the right signal; with testRun equals false test runs stay out. If the automation starts a flow again, the chain keeps counting — it stops after five steps so that flow and automation cannot trigger each other forever.
Create personal automations. A personal automation belongs to you alone: you create it with the Personal automation switch (anyone who may only manage their own automations always creates personal ones), and it appears in the Personal group and under My automations. It acts only on records you yourself may see, and never with more than your permissions: a ticket of a brand you cannot read, or a private work item whose circle you do not belong to, does not trigger it. Without management rights you can choose Notification (to yourself only), Create task, Set field, Add/remove tag, Adjust score, Assign work item and AI step — each only if you could do the same by hand. The AI step rests while AI is switched off. Only you and the automation managers can see a personal automation; if you are deactivated or leave, the system switches your personal automations off.
Tasks for the AI team. The action Give task to AI team member creates a task and assigns it to an AI team member — directly or by its job profile. With the schedule trigger it becomes a routine; the template Weekly report of the team lead to the owner is off at first. More in the AI team.
Filter and tidy up. The filter bar above the list narrows by origin, plugin, category, trigger, Mine (only your personal ones) and — for managers — Type (personal or brand/global); the selection lives in the address and can be shared as a link. Clear filters resets it. A brand-bound automation shows its brand next to the name. Suspended automations are marked separately.
AI costs at a glance. If an automation called a language model in the last 30 days, AI … / 30 days with the amount from the AI log appears next to its name. If its AI step runs on every trigger — because neither a condition of the automation nor a branch or step condition before it cuts it off — AI on every run appears as well: a condition before the AI step then saves costs, often a step without AI is enough.
Fields in detail
The What it does column answers what changes in the system — not what the field is called. The grey name behind the label is the API field: the same thing runs under that name through automation, import and AI tools.
Creating and editing an automation
| Field | Required | Values / format | What it does |
|---|---|---|---|
Name name | yes | text, max. 255 characters | What the automation is called. It appears in the list and in the log of every run — a telling name saves searching when something unexpected happens. |
Description description | no | text | What it should do and why. The paragraph that answers, a year from now, whether it may be switched off. |
Trigger type triggerType | yes | event, schedule, relative, manual | When it runs. Event reacts to something in the system, schedule runs by the clock, relative counts from a date (three days before a contract ends), manual only on demand. |
Event triggerEvent | with "event" | text, max. 255 characters | What is reacted to — say "invoice issued" or "ticket assigned". |
Schedule cronExpression | with "schedule" | schedule expression, max. 100 characters | When and how often. |
Relative settings relativeConfig | with "relative" | reference date and offset | Which date is counted from and with what lead time. That is how the reminder arrives before the date rather than after. It runs once per record — for a yearly date (e.g. Birthday (yearly)) once per year; 29 February counts as 28 February in years without a leap day. With the reference date Cart: last activity once per state of the cart. |
Conditions conditions | no | condition tree | Whether to act in the individual case. Without a condition the automation runs on every trigger — rarely what is wanted. |
Steps steps | yes | list of steps | What is done: set a field, send a mail, create a task, wait, ask the AI, repeat for every entry of a list. The order is the execution; a wait really pauses the run instead of polling. A task takes customer and document from the trigger (invoice, order, return, purchase order …) unless the step says otherwise — so it sits on the account and on the document instead of starting as free text. |
Category category | no | text, max. 50 characters | Classification in the list. With many automations, the difference between overview and undergrowth. |
Brand brandId | no | one of your brands | Which brand the automation applies to. Empty means all. An automation with a brand only reacts to triggers that carry the brand of their record — among them creating, changing and deleting customers and contacts, creating and changing products, stage changes, qualification and conversion of leads, and creating, stage changes, winning and losing of deals (for example Deal won for one brand only). It cannot be saved switched on for a trigger without a brand, because it would never run there. |
Personal personal | no | yes/no, only on creation | Whether the automation belongs to you alone. It then acts only on records you may see and only with your permissions; you and the managers can see it. The owner (ownerUserId, ownerName) is fixed from then on. |
Active active | no | yes/no | Whether it runs. A new automation belongs created off, checked against an example and then switched on — not the other way round. |
Steps
Every entry of the Steps list carries these fields:
| Field | Required | Values / format | What it does |
|---|---|---|---|
Type type | yes | action, branch, wait, goal, loop | What the step is. A loop repeats the following steps per entry of a list. |
Action actionType | with type "action" | key from the catalog | Which action runs — say "create task" or "send email". |
Position position | no | whole number | Order; jump targets and the end of a loop body name positions. |
Settings config | per type | object | The settings of the type — for an action its fields, for a wait the duration, for a loop the list (see below). |
Branch condition branchConditions | with type "branch" | condition tree | Whether the run continues; inside a loop body a branch that is not met only ends the iteration. |
Step condition stepCondition | no | condition tree | Whether this one action step runs; not met means skipped, the run continues. |
Identifier ulid | no | assigned by the system | Kept when saving. |
Loop
The loop reads its settings from config:
| Field | Required | Values / format | What it does |
|---|---|---|---|
List config → items | yes | placeholder or enumeration | What is repeated over. A JSON list, a JSON object (the key is then in {{ loop.key }}) or text separated by comma, semicolon or line. An empty list skips the body. |
Steps inside the loop config → loopEnd | yes | position of the last body step; in the editor the number of following steps | Which steps run per entry. A loop inside a loop and a goal step inside the body are not possible. A branch that is not met inside the body only ends the iteration, not the run. |
Maximum iterations per run config → maxIterations | no | 1 to 1000, empty = 100 | Protection against an unexpectedly long list. Anything beyond is not processed — the log states how many. |
Continue on error config → continueOnError | no | yes/no | Whether a failed iteration only ends itself. Without the switch the whole run ends as failed and the log names the iteration. |
After the loop, {{ step<position>.iterations }}, .failed, .total and .truncated are available to the following steps.
Every run is logged: with trigger, evaluated conditions, executed steps and result. That is the only way to show what an automation did — and the place to look before blaming it.
Settings & permissions
platform.automation.readto view,platform.automation.manageto create and change,platform.automation.run
to execute and to dry-run.
platform.automation.manage_ownfor personal automations: create, change, test and delete —
your own only. The standard roles Vertrieb (sales), PM, Umsetzung (delivery) and Support carry it.
- The active state survives updates. Whether a shipped automation is active is your decision. A
system update does not reset it.
- Automations act as their own actor. Whatever an automation changes appears in the
audit log with Automation as the actor — cleanly separated from human actions.
- Waits are real waits. A rule with a delay blocks nothing and resumes by itself later.
FAQ & troubleshooting
How do I react to an abandoned cart? Trigger event with Cart abandoned (CartAbandoned) — it comes from the sales channels as soon as a cart with an address rests for an hour. After a wait the condition checkout.ordered checks freshly whether an order has been placed meanwhile; Cart ordered after all (CartRecovered) is the counter-trigger. Ready-built, this is the abandoned-cart reminder.
The template gallery is empty. Templates come from modules. If the relevant modules are switched off or not installed, there is nothing to offer.
My automation does not run. Check in this order: is it active? Is it suspended? Does the trigger genuinely apply? Are all conditions met? The Last run column shows Never if it has not yet fired.
**I cannot see New automation.** Then you lack both platform.automation.manage and platform.automation.manage_own.
My personal automation ran but did nothing. The log names the reason: you were not allowed to see the triggering record, or the action requires a permission you lack. A personal automation deliberately skips such events — it never does more than you could yourself.
An automation did too much. The dry run would have shown it. Switch the rule off and trace the effects back through the audit log using the request identifier.