Automation is the add-on for routine work: it does the repetitive chains for people, by the simple rule “when this happens, do that”. Rules and multi-step processes are assembled from ready-made conditions and actions, with no programmer involved, and every step leaves a line in the journal — you can see what fired and why.
Why you need it
Most of the work with customers consists of repeating chains: a new lead arrives — assign an owner and set a reminder to call; an invoice is paid — move the deal to the next stage and make the manager’s day; a customer goes quiet for two weeks — remind someone about them; a ticket is overdue — raise its priority and warn the manager. While the product cannot do this, everything rests on people’s memory and discipline, and part of the work is simply lost. Automation sets such chains up once and then runs them without reminders.
There is a separate benefit — predictability. When a rule is written down explicitly, nobody has to explain to a new colleague “this is how we do things here”: it is visible in the rule itself, and it fires the same way for everyone.
A rule: when this happens, do that
A rule has two parts: the condition that triggers it and a set of actions. Conditions are assembled from ready-made fields and comparisons — “the deal amount is above a million”, “the stage changed to Negotiation”, “the customer has had no activity for 30 days” — without a single line of code. If a condition or an action mentions something a record does not have, the rule simply will not save: the product names the field it does not understand, so no empty rule that silently does nothing ever reaches production.
One rule can carry up to ten actions. Steps that launch other rules nest no deeper than three levels — that way chains do not turn into an unreadable tangle in which you cannot tell what fired after what.
When a rule fires
Any of the usual events can start a rule:
- A record is created, changed, deleted or moved to another stage. You can watch not the whole record but a specific field — for example, only a change of the owner or of the amount.
- On a schedule. For example, checking every morning for tickets with no answer.
- By hand. An employee starts the rule themselves for one record or for a whole selected group.
- By a domain event. A request came in, an invoice was paid, a document was signed.
- By a signal from another chain. That is how rules and processes talk to each other.
- By an outside call. A rule can have a protected intake address: an external system tells the product about an event, presenting a secret key.
- By a metric. The rule fires when a number leaves its usual range — for example, when the count of overdue tickets jumps.
What a rule can do
Actions are a ready-made set too: create a record or add to an existing one, update fields, link records to each other, send a letter from a template, notify an employee, assign an owner, call an external system at a protected address, create a task, move a deal to another stage, write a line into the journal.
Letters leave through the same sending gateway as mailings, so customer consents and stop lists are honoured automatically: a rule cannot “accidentally” write to someone who asked not to be contacted. And if a letter still contains an unfilled placeholder (a field the customer simply does not have), the letter is not sent with a blank in it — it is refused with an explanation of which placeholder could not be resolved.
Processes: several steps and people taking part
When a chain is longer than a pair of “condition — action”, it is more convenient to describe it as a process. A process has a start, steps, branches, waits and a finish. Steps know how to wait: a pause for several days, waiting for a customer’s reply or for a particular event, waiting until the working day begins. Waiting costs nothing: a process does not hold resources and does not spin idle — it simply waits for the right moment, and there can be as many waiting processes as you like.
A process can include a step for a person: “approve the discount”, “check the contract”, “confirm the refund”. Such a step stops the process and waits for an employee’s decision — approve, reject, or send back for revision with a mandatory explanation. The decision is made by a living person in the interface: neither a rule, nor the agent, nor the management key can “approve” instead of them. Decisions are visible on the “Approvals” screen, and the decision journal is never rewritten after the fact: if a dispute arises over who approved a discount and why, the answer is there.
One process can call another — for example, a shared new-customer registration process called from several different places. Up to twenty live nested processes can run at the same time.
An important detail: a process that is already running lives by the version it started with. If the definition is edited, a running approval does not change halfway through — otherwise a request sent under the old rules would close under the new ones.
Dry run, quiet mode and forecast
You cannot switch a rule on blindly. Before activation the product counts how many records would fire right now and shows that number; if the count went stale after the last edit of the rule, activation is postponed until a fresh count is made. That is how you avoid surprises like a thousand letters on the first day.
There is also a quiet mode: during a data migration or maintenance work the product suspends letters and launches — visibly, with the reason stated, not silently. Whatever was missed during the pause is handled by each rule’s own missed-window policy: some things catch up, some are skipped with a journal line. For a bulk launch over a large selection the product says in advance how many records will be touched and how many people will receive a letter.
Journal and automation health
Automation has no black box. Every run and every one of its steps leaves a line: when, under which rule, over which record, and what came of it. Secrets never reach the journal — passwords and keys are not stored there in the open. If a step fails, the product retries it the prescribed number of times, and a run that ultimately fails stays in the journal with the error text and a re-run button.
There is also an automation health report: you can see which rules have not fired for a long time (perhaps they are no longer needed and should be removed), where failed runs are piling up, and whether any metric has drifted off course. The limits are honest numbers too, and they are listed in one answer: how many actions a rule carries, how many nesting levels are allowed, how many steps in a row are permitted, and how long journal entries are kept (steps for 90 days, runs for a year). None of it has to be discovered by trial and error.
Honest limits
- There is no programming inside rules. Conditions and actions come from a ready-made set, and formulas from a limited set of expressions. If you need real code, that is what the separate Scripts add-on is for.
- There is no graphical process designer. Processes are described as a list of steps and links, not by dragging boxes around a canvas. That is enough for most working processes, but there will be no drawn diagram “like in the books”.
- The process notation is only partly supported. Some of its features (swimlanes and simulation, for instance) are deliberately not built: they would be more complicated than the task itself.
- Each contour keeps its own mechanisms beside it. Deal automation, marketing touch sequences, lead distribution and service queues work on their own and were not moved into the shared engine. That means their firings have to be watched in two places — a deliberate decision, not an unfinished part.
- An approval is always confirmed by a person. Neither a rule, nor the management key, nor the agent can approve a discount or a contract on an employee’s behalf: “approve” can only be pressed in the interface under your own sign-in, and every decision keeps its author.
Next → Python Scripts