Shipping

Builds "when this happens, do that" rules without programming. The real risk is the cascade: an automation that triggers another can enter a loop — test with one case before turning it on for the whole base.

Create automations without programming: choose a business trigger (lead created, invoice overdue, contract signed, ticket opened, stock at minimum...), define the conditions and what should happen (notify someone, open a request, call a webhook, move to a stage). Start with the gallery of ready-made recipes — installs in 1 click — or build your own. Before turning it on, use the Dry-run to see what would happen with an example, without executing anything. Each trigger is recorded in the log.

Besides the six business events that already existed (lead, opportunity, overdue invoice, contract signed, ticket, minimum stock), an automation can now also start with:

• At a time I set — you write "every Monday at 8am" or "every 5th" in plain language, click Understand and check what was read before saving. If the phrase isn't clear (for example "every first business day", which depends on the holiday calendar), the platform says it didn't understand instead of choosing a date for you.
• When someone changes a field — choose the record and the field. The context brings before and after, so you can condition on the new value (e.g.: field after equal to WON).
• When a date is getting close — choose the date and the lead time. Each record warns only once: the platform keeps track of who has already been warned today, otherwise the same contract would show up every day until it expired.

The list shows each automation with name, trigger, origin, whether it is on and when it last ran; the row button switches it on or off. At the top are the gallery of ready recipes (installing creates the recipe switched off), the waits in progress and the latest executions with what happened in each.

Each trigger and each action has at least one installable example in the gallery at the top of the screen. Installing copies the recipe to your account turned off: you open it, adjust the text, run the Dry-run with an example and turn it on when it's the way you want.

It's the fastest way to understand what each piece does — including the OR between groups, IF/ELSE and the wait, which have a recipe just to show them working.

Within a group, all the conditions must be true. When you click Add an alternative path (OR), a second group is created — and one whole group matching is enough for the automation to fire.

Example: one group with "source = website" and another with "source = referral" fires in both cases, without needing two automations.

With no condition filled in, the automation fires every time the trigger happens.

The Wait a few days action pauses what comes after it. When the time is up, the automation's conditions are checked again, against today's data, and only then does the rest of the script run.

That's what makes "wait 3 days; if they still haven't paid, chase them" really work: if the customer paid in the meantime, the wait ends without chasing, and the history records the reason. Continuing without re-asking would chase someone who already paid — and technically nothing would have gone wrong.

While it waits, the script appears in the Waiting on the clock block, and you can cancel it. Turning the automation off also cancels whatever it left in the oven.

The Request a platform action action uses the same governed catalog as Tenkai (open a ticket, collect a receivable, extend a due date, move a stage…).

It acts on behalf of whoever created the automation: that person's screen permission, profile verb and the company's approval limits apply. An automation written by someone who can't give discounts doesn't give discounts — it's refused with the same reason that would appear on screen.

🔒 An action that involves money is never confirmed on its own: it waits for your confirmation for 24 hours, and you receive a notice with the code to confirm or cancel.

The Update a field action has three deliberate refusals, always with the reason in the history:

• Receivable/payable — money moves through the approval path, not through direct assignment. Use "Request a platform action".
• Identity and audit fields (company, account, creation dates, who changed it) — they're what answer "whose is this" and "who touched it".
• A field that doesn't exist in the record — instead of saving nowhere, the action refuses and says which field it didn't find.

To save a field you created in the Field Studio, write the key with the prefix custom. — for example custom.centro_custo.

On the record, the trigger "at the time I set" requires writing when to run and clicking Understand; "when someone changes a field" requires the record type and the field; "when a date is near" also requires the lead time. Without it, Save refuses — the recipe would be born mute, with no error. The automation is born switched OFF.

Switching off or removing an automation cancels its pending waits: a WAIT action that would expire later does not act on behalf of a switched-off automation. Removing sends the recipe to the trash, from where it returns via Undo or the list’s trash. Before switching on, use the Dry-run in the record header to see what would happen with an example.

No. The automations clock checks times every 15 minutes, so the routine can run up to 15 minutes after the scheduled time. What does not happen is skipping: if the exact minute fell between two checks, it runs at the next check.

And the same time never fires twice — each automation keeps track of when it last ran.

The changed-field trigger only works on records that keep a change history — the comparison between the old and new value comes from the history. A record without history has no "before" to compare.

Also check that the chosen field is the same one being changed on screen: the list shows the record's real fields, and switching records clears the chosen field on purpose.