How do you keep hundreds of CRM automations maintainable?

01The business problem

One business event usually needs several unrelated things checked. Take an account moving from prospect to customer:

• If the primary contact details are missing, tell the owner — otherwise every later automated email addresses nobody.
• If the region was typed as a two-letter abbreviation, expand it, because otherwise reporting by country silently splits into duplicates.
• Populate the renewal dates from the contract term, which is either twelve or twenty-four months.

These are not alternatives. A single account can need all three, and they have nothing to do with each other. The instinct is to write one process for "account becomes a customer" that handles all of it — and that instinct is what §2 is about.

The estate this is drawn from carries 265 processes across seven entities, with 113 on one entity alone. That number is not sprawl and it is not a warning. It is what the engine's shape produces when a business has this many rules, and the interesting question is not how to have fewer but how to keep hundreds legible.

02Why the obvious approach fails

Putting all three checks in one process

This is the single most expensive misunderstanding available in the process engine, because the design looks tidier and the failure is invisible. It also gets worse with success: the more cases the process covers, the more likely a record matches several and receives one.

Nor can you re-gate mid-chain to get round it. A filter may never be a child of an action — the canonical shape is trigger, then filter, then actions, and the engine will not accept a second gate hanging off the end of the first one's work. Independent conditions therefore cannot be expressed inside a single process at all. That is a structural fact, not a style preference.

Descriptive names

Naming a process after what it does — Send the welcome email, Update the renewal date — is clear on the day and useless in a list of two hundred, because the list then sorts by verb. Everything beginning Update… lands together regardless of what it touches, and the six processes concerning one domain scatter across the alphabet. You read the list far more often than you read any single name.

Documenting it in a spreadsheet

Accurate the day it is written, wrong within a month, because the estate changes in the admin interface and the document does not. Anything maintained in parallel with the thing it describes will drift. What survives is what lives in the estate — which is why the name carries so much weight.

03The shape of a process, and what follows from it

Everything in this blueprint follows from one structural fact:

trigger  →  filter  →  actions
              ↑
              exactly one, at the root.
              A filter may never be a child of an action.

Which means a process can apply one independent condition. A second condition needs a second process — and the way you get there is a trigger-process node, which hands off to another process and carries its own filter. The next condition lives on the handoff.

So the prospect-to-customer example is not one process. It is a detector plus three sub-processes:

Each sub-process evaluates its own condition independently, so an account needing all three corrections gets all three. That is the whole reason the estate is shaped this way.

04Trigger type is a first-class fact

There are four trigger types, and the type determines both how a process is reached and how it fails. This belongs in how you think about the estate, not in something you discover by opening a process.

05Patterns that keep a large estate legible

The name is the index, so prefix by domain

There is no folder, no tag and no dependency view. The name is what you will search in a year. Put the domain in brackets at the front:

[Contracts]  Create the renewal record
[Contracts]  Watch the renewal date for changes
[Hygiene]    Normalise country and region codes
[Hygiene]    Flag records whose status contradicts their dates
[Outreach]   Send the scheduled check-in

A flat list then groups itself when sorted, a search for one domain returns everything touching it, and adding a process forces the question which domain is this? — which is what catches a duplicate before it exists.

The estate examined uses about a dozen prefixes, the largest carrying twenty-five processes and the smallest two. That distribution is itself a review tool: twenty-five members is a domain worth reading as a whole, and two is either a genuine edge or a naming accident.

Name the chain, not just the process

Because sub-processes are reached by being called rather than by watching anything, the only clue about who calls whom is the name. A shared prefix plus a consistent verb for the detector — the process that owns the event — makes a chain readable from the list alone. Without it, tracing one business event means opening processes until you find the caller.

One sub-process serves as both subroutine and repair tool

Because manual means callable and runnable, the sub-process you built for the chain is also the thing you run by hand when a date moves, a record is created out of order, or an automation was disabled for an afternoon. This is the same mechanism as the manual twin in Blueprint 010 and the re-runnable derivation in Blueprint 009 — not a separate pattern, the same one seen from a different angle. Build it once and it does both, provided it keeps its own root filter.

A final unmatched branch that says something

Any filter that maps a value to an outcome should end with a branch matching everything the earlier ones did not, whose action is to tell somebody. Given first-match-wins semantics, an unrecognised value otherwise takes whichever fall-through exists and produces no error at all. Cheapest insurance available in an estate this size.

06Limits & trade-offs

The decomposition in §3 is required. The consequences below are not required — they follow from a second absence: the platform gives you no feedback about your own estate. Nothing reports when a process last fired, what calls it, or what would break without it. In an estate where half the processes are reached only by being called, that missing call graph is the expensive part.

Nothing gets deleted, so things get renamed

The mitigation is a convention, not a tool: retirement means disabled first, renamed second, deleted on a date you write into the name. A process marked as unused and still firing is worse than either state on its own, because the name tells the next person to ignore something that is actively doing work.

Duplicates accumulate by year

Anything with a year in its logic tends to be copied rather than extended each January, and the older copy is never retired. This estate carries several such families where two processes do largely the same work over different year ranges. Each was the correct minimal change at the time; together they are two places to update and a coin-toss over which one actually ran.

Scheduled processes collide, and nothing warns you

Scheduled times are chosen one at a time, with no view of what is already scheduled. In this estate three unrelated daily processes run at the same hour, and others sit five and twenty-five minutes apart.

Same-time scheduling is not itself a fault. It becomes one when two of them touch the same records, because there is no ordering guarantee between them and no transaction around either — so which one wins is not something you can reason about from the configuration. Keep a single list of scheduled times and their owners, and space anything that shares a record set.

An orphaned sub-process cannot be distinguished from a working one

This is the failure mode the composition model introduces. A sub-process is reached only by being called. Disable or rewrite its caller and it stops being reached — while continuing to look exactly like every other enabled process in the list. Its filter is still correct. Nothing consults it.

It is also the one form of dead process you can actually prove dead, because the call is in the caller's own definition. That makes call-chain tracing the highest-value audit in §7, and the only way to clean up an estate with confidence rather than nerve.

Personal processes are a real category

Estates of this size contain processes prefixed with somebody's initials — personal tools built for one person's routine. They work, they are used, and they are invisible to everyone else. Give them a shared prefix and put what they do in the name, because the alternative is that they become unowned the day that person changes role.

What we have not verified

The structural claims — one filter at the root, a filter never a child of an action, the four trigger types, the handoff node carrying its own filter — are read from the API schema and from process definitions captured out of the administrative interface. The first-match-wins behaviour of a filter's branches, and the estate figures quoted throughout, come from operating this deployment.

We have not tested whether the platform offers per-process execution telemetry, bulk enable and disable by name pattern, or a call-graph view. The practices above assume it does not, because that is how this estate is managed in practice — but absence of use is not proof of absence. If you are setting conventions for a new space, check the current administration interface before committing to compensate by hand.

07Verification

This is the audit for an estate you did not build, and it works from the outside. All of it reads the process list rather than opening processes one at a time.

• Group by name prefix and look at what has none. Unprefixed processes are usually the accidents — added in a hurry, never revisited. Count the distinct prefixes too: more than about fifteen means the scheme has stopped being a scheme.
• Check for singular and plural of the same prefix, and for the same domain spelled two ways. This is the most common silent failure of a naming convention and it takes thirty seconds to find.
• Group the scheduled processes by time of day. Anything sharing an hour is worth a look; anything sharing an hour and a record set is worth fixing.
• Search the names for not used, obsolete, old, temp, copy, and for personal initials. Then check whether each one is actually disabled. The gap between "named as dead" and "switched off" is where this audit earns its keep.
• Trace the call chains. For every manual-trigger process, find what invokes it. The ones nothing invokes are genuinely dead — and this is the only kind of dead process you can prove, because the call lives in the caller's definition rather than in inference. Do this before anything else if you inherited the estate.
• Count manual against record-triggered. A high manual fraction on a mature estate is expected and healthy — it is the composition layer. What matters is whether each one has a caller. A high manual count plus orphans is the signal that a chain was rewritten and its parts left behind.
• Check every multi-branch filter for independence. Where branches represent alternatives — a status is one of four values — one process is correct. Where they represent conditions that could all be true at once, first-match-wins means only one will ever apply, and the others need extracting into sub-processes. This is the audit that finds the §2 error in an estate somebody else built.
• Try to state each process's purpose in one sentence. The ones you cannot are the ones carrying more than one concern, and they are the candidates to split — not because they are broken, but because they are the ones nobody will dare change later.

What would signal a regression: a new process with no prefix, or a prefix not on the agreed list; a manual-trigger process with no caller; a multi-branch filter whose branches are independent conditions rather than alternatives; a process named as retired that is still enabled; two processes whose names differ only by a year; a scheduled process added to an hour that already has one touching the same records.

Related blueprints

• Blueprint 010 — the fan-out pattern in practice: one date change written as four processes rather than one, and why each wants a manual twin.
• Blueprint 009 — why on-change processes fail silently, what a scheduled process does with stale inputs, and the re-runnable derivation that repairs both.
• Blueprint 003 — the question that prevents estate growth in the first place: whether something needs building at all.