The Rule That Waits Three Days — and Checks the Stage Again
Most automation rules in a CRM should fire at once: a deal moves to a new column and a task appears, an invoice is paid and the bookkeeping entry is written. Some steps, however, are only useful after a pause. Firmspace therefore lets a rule act immediately, after one hour, after one day or after three days. The interesting part is not the waiting. It is what the system does when the waiting ends.
The trigger remains an event. Deal stages are one place where this matters. When a deal changes stage, the CRM records which deal it was and which column it landed in, together with the contact and the responsible person. The rule matches the event type and, optionally, one specific column. That is why a rule can be tied to 'Offer sent' without catching every other move on the board.
When the delay is longer than zero, the delayed action is not kept in a browser tab. The CRM writes a job: the rule, a copy of the event and the moment it becomes due. The tab may close, the laptop may sleep, the person who moved the card may go on holiday. The job remains in the database.
The queue is drained by the daily server cron and, in addition, when the application checks notifications; the notification check is throttled to one pass per twenty seconds per firm and takes up to twenty-five due jobs at a time. In practice a three-day rule fires on the next pass after the deadline, not at the exact minute. For a sales follow-up that is fine. For a payment deadline it is not — that is what the invoice reminders are for.
Before the action runs, the rule is read again. If somebody deleted it or switched it off during the wait, nothing happens. A rule that no longer exists must not send an e-mail that nobody expects.
For deal events there is a second check. The deal is loaded and compared with the stage the rule was written for. If the deal has moved on, the job is closed with a short line in the log: skipped, the deal left this stage. This is the difference between a reminder and a queue of stale messages. A customer who has already signed does not need a nudge about the offer.
The job is claimed with a conditional update: only one worker can turn 'not done' into 'done'. If two tabs, two employees or two server instances poll at the same moment, one wins and the others move on. Without that, a delayed e-mail could go out twice — a mistake that is cheap to prevent in the database and expensive to explain to a customer.
A delayed rule can also carry an AI action. The assistant receives the event data and the instruction written by the firm, may read records to find the right person or deal, and may execute at most one write tool. Four steps are the ceiling. It works with the owner's rights because there is nobody to confirm at night — which is exactly why the instruction should be narrow: check the deal and prepare a follow-up note, not handle the customer.
Two limits follow from that. The AI action spends the same daily quota as the chat, and the firm's plan must include the autonomous automation step; without it the rule stops with a clear message instead of improvising. Read tools leave no trace in the data; the single write is the only thing that can change a record.
Every run leaves a line in the Firmspace CRM automation log: rule name, date, success or error, and a short message — what was sent, which task was created, why the rule was skipped. The log keeps the last two hundred entries. That is how a firm answers the question 'did the system actually do it?' without opening server logs.
The pattern that works is simple: put the delay where a human would normally wait anyway. One day after the offer, a sales follow-up task for the responsible person. Three days before the contract starts, a check that the signed copy exists. The delay does not make CRM automation smarter. It makes it behave like a colleague who remembers to come back.