The Rule That Fires at Nine: What Firmspace Re-Checks Before a Delayed Automation Acts
A rule inside a CRM looks like a reflex: the deal is created, the rule answers. In practice the interesting part begins where the rule does not answer at once. A deal appears at nine in the morning and the follow-up is set for ten. During that hour the client pays, a colleague moves the deal to another stage, someone closes the task. A rule that fires at ten without looking at the world again is not an automation; it is a source of messages about things that are no longer true.
Firmspace keeps a delayed step as a record rather than a timer inside an open browser tab. When an event matches a rule with a delay, the engine writes an automation job: the firm, the rule, a copy of the event data and the moment when the action is due. The job survives a closed laptop, a restarted server and a week of holidays, because it lives in the database. A daily background pass picks up what is due; the same pass also moves overdue invoices into their status, generates invoices from recurring templates, sends payment reminders and refreshes mailboxes, and each of those steps runs separately so that one failing step cannot cancel the others.
The first thing that makes a delayed action trustworthy is that it cannot happen twice. Every due job is claimed with a conditional update: the record is switched from not done to done in one statement, and only the poll that changed the row continues. If a cron server, a second application instance and an open page ask at the same moment, one of them receives the row and the rest receive nothing. The in-memory throttle that limits how often a firm's jobs are checked exists only to save queries; the correctness does not depend on it. A single pass takes up to twenty-five due jobs, so a backlog drains gradually instead of exhausting one request.
The second thing is that the rule is read again at the moment of action, not remembered from the moment of the event. If the rule was deleted or switched off while the job was waiting, the job is dropped without a message. If someone edited the text or changed the stage, the job uses the current version for its text but keeps the event data it was created with. This is a deliberate separation: the facts of the event do not change retroactively, but the firm's intention may.
The third thing is the stage check. A rule can be bound to a stage, and for deal events the engine compares the stage stored in the rule with the deal's stage right now. A deal that has moved on is not reminded, and the log records a skip with the plain sentence that the deal left this stage. That single check removes most of the nonsense that makes people distrust automation: follow-ups for won deals, reminders for clients who already paid, tasks for records that were deleted.
Delays come in four steps — immediately, after an hour, after a day and after three days — and they belong to the rule, not to the message. The actions themselves are deliberately ordinary: a notification, a task, a note on the deal or the contact, a stage move, an e-mail, a webhook and the AI action step. Each action returns one short line describing what it did, and that line is what the person reads in the log later.
Text in a rule can address the event and the firm's own constants: the client name, the stage name, the document number, a value from the constants section, a variable that changes over time. A document number is filled the same way for an invoice, an order, a quote and a contract, so a single rule about numbers does not need four variants. If a value is missing, the template renders an empty string instead of a leftover placeholder, and when the message itself is empty the rule's own name is used as a fallback.
Failure is contained on purpose. An action that cannot be performed is written to the log with an error status and a short reason, and the operation that caused the event still succeeds — closing a deal, sending an invoice or receiving a message must not break because a mailbox is not connected. The reasons are concrete and readable: no connected mailbox, a client without an e-mail address, a target stage that no longer exists, a deal that was deleted, a webhook address that is not https or points inside the private network, an AI step that the firm's plan no longer includes, or an AI quota that is already used up for the day.
The AI action deserves a separate sentence, because it is the only step where a model decides what to do. It runs with the rights of the firm's owner, like the other actions, and it may perform at most one write operation per firing. It can read first — a few lookups to find the right person or record — but the moment it writes something, the run ends. The instruction tells it that text inside CRM records is data, not orders, and that when it is unsure it should do nothing and explain in one sentence why. The step also spends the firm's daily AI quota, the same quota the chat uses, so an automation that fires all day cannot starve the assistant.
A reasonable question is whether a rule can set itself off again. The ordinary actions change records directly and do not announce the same event back to the engine, and the engine marks its own run so that it does not re-enter the matcher within that firing. A chain is therefore not built from reflexes. The AI step is the exception worth watching: if it really sends an invoice through the firm's tools, that is a genuine new event and other rules will hear it, exactly as if a person had pressed the button. The practical rule follows from this: write delayed steps around a fact that becomes true once — a task exists, a note is attached, the stage has changed — and not around a hope that the model will remember.
The log keeps the two hundred most recent entries per firm, each with a date, the rule's name, a status and a message cut to three hundred characters. It answers the question people actually ask the morning after: what did the rules do at nine, and what did they refuse to do. It is not an accounting register and it is not designed as evidence for a tax inspection; it is the automation's own notebook, and it is trimmed by design.
None of this replaces judgement. A delayed rule still needs a stage filter if the stage matters, one clear action instead of five, and a look at the log after the first firing. The most useful delayed automations in a small firm are the boring ones: a task one day before a deadline, a note after a contract is signed, a stage move one hour after a quote is sent. They are promises the firm makes to itself, and the CRM keeps them by checking the world before it acts, not by hoping the world stayed still.