Rules

The decisions a tool applies, written down once.

Matching, survivorship, normalization schemes, segments, scoring models, routing policy and field mappings. Saved on the connection, not buried in whoever ran the job last.

The gap this closes. The policy exists. It lives in the head of the person who ran the last cleanup, or in a spreadsheet attached to a ticket from two quarters ago. Nobody can reproduce last quarter's result because nobody wrote down what it meant.

Rules are configuration in the strict sense: a saved decision that outlives the operation using it. A run points at them; it does not carry a copy.

Each tool has its own sections. Deduplication has three, because matching, choosing the master and choosing the surviving field values are genuinely separate decisions. Most tools have one. Mass Update has none at all, because its instruction is the run itself.

They are keyed to the object. Accounts, contacts and leads each get their own, since a rule that works on a company rarely works unchanged on a person.

The distinction

What belongs in a rule, and what belongs in a run.

The split is what lets one policy serve many operations, and it is the thing most CRM tooling gets wrong by putting everything in the job.

Saved as a rule

Stable. Written once, read by every run that points at it.

What counts as a duplicate on this object
Which record survives a merge, and which values it keeps
The canonical form a field should take
The routing policy: pools, strategy, owner field
Segments and scoring models, with their bands and weights

Carried by the run

Situational. Decided per operation, because it is about this pass rather than about policy.

Which records this operation covers
Who releases the writes, and whether a person reviews them
What to spend, where a provider is involved
The instruction itself, for Mass Update, which has no saved rules

How it goes

From nothing to a record of what happened.

Pick the tool. The sections you see are the decisions that tool actually makes.
Pick the object. Accounts, contacts or leads, each with their own.
Author. Build the rule against your real field catalog, not a generic schema.
Use it. Runs point at it by name. Editing it changes what the next run does, never what a completed one did.
Read the log. Every change is recorded, and the last one can be undone.

The change log

Configuration changes are history too.

What it was, what it became, and who did it.

Every change to the configuration that decides what runs do is recorded, newest first, with the before and the after. That log is deliberately separate from the CRM write log, and the page says so plainly: nothing here touched a record.

The distinction matters when something goes wrong. A record with the wrong value has two possible causes, a bad write or a bad rule, and they are fixed in completely different places. Two logs answer that question in one look. The most recent change can be undone from the log itself.

For agents

The same surface, over MCP.

Reads are free and need no permission to write. Anything that changes a record is a separate grant.

list_rule_templates the rules on this connection read

get_rule_template one rule, in full read

get_default_rule_config what a tool does before you configure it read

create_rule_template author a rule write

update_rule_template change one write

delete_rule_template remove one write

The rest of it

How the pieces fit.

The Console: Describe the outcome in a sentence. Reads answer immediately, writes are held as a plan you confirm.
Runs: One saved, scoped operation. It owns the findings it produced.
Plans: An ordered sequence of runs, fired on demand or on a schedule.
Tools: The eleven things a run can be, one per kind of drift.

Where to start

Start with what is already in there.

The readiness scan reads your CRM and reports what it finds, before you describe a single change.

Run a readiness scan Request a demo