CRM cleanup shouldn't be a quarterly fire drill. I put it on a schedule that can't change anything alone.

Why cleanup keeps coming back

Duplicate contacts, stale deals and half-filled records pile up faster than anyone cleans them. Reports drift, reps stop trusting the numbers, and cleanup becomes a quarterly project that one person dreads. The HubSpot UI turns it into a clicking marathon. A script is faster but has no preview and no undo, so one wrong filter rewrites thousands of records.

An approval gate helps with a single job. It doesn’t help with the job that comes back every Monday. If I have to remember to ask for the cleanup, it doesn’t happen. And if the agent runs it unattended, the gate is gone.

hubspot-claude now has three pieces that close that gap: schedules, pattern approval, and risk tiers. All three shipped on July 22.

Cleanup on a schedule, changes on your approval

A schedule is a saved cleanup plan with a cron time: “every Monday at 09:00, find deals with no activity in 30 days and propose closing them as stale.” The plan has to be concrete. Every step names the exact tool it will call. A free-text plan is refused outright, because a vague plan run unattended is how an agent ends up improvising against your live data.

When the schedule comes due, the plugin runs the reads and stages every write as a pending preview. Nothing is changed in HubSpot. On Monday the batch is waiting under “pending approvals”, grouped by schedule. I approve it like any other change.

Two rules make this safe to leave running. First, a schedule doesn’t run again while its last batch is still waiting for review, so unreviewed work can’t pile up. A batch nobody reviews expires after seven days. Second, approval can come days after the run, and HubSpot keeps moving in between. So every staged write is checked against the record again at approval time. If a rep edited the deal since the run, that write is skipped and reported, not forced through.

The design rule underneath, in the project’s own words: unattended mutation stays a non-goal. The schedule does the finding. A person does the deciding.

Approve the rule once, apply it to every record

The second piece solves a different kind of fatigue. If a cleanup touches 800 records, reviewing 800 previews isn’t review. It’s a rubber stamp with extra steps.

Pattern approval lets me approve the rule instead: “normalize the industry value ‘Saas’ to ‘SaaS’ on every company where it appears.” The preview shows how many records match and three samples of the before and after. Above 100 records, I type the count to confirm, the same check the plugin uses for anything destructive. Then it works through the set one record at a time, and before each write it checks that the record still looks the way it did in the preview. Anything that drifted is skipped, never overwritten. The result comes back as three numbers, applied, skipped because it drifted, and failed, plus a single command that undoes the batch.

This feature was on the “killed” list for a while, marked as too risky if the records diverged from the sample. The per-record check is what brought it back.

Two limits are deliberate. Pattern approval only works for updates, not deletes or merges. And it refuses rules that touch sensitive fields like deal stage, deal amount, owner or lifecycle stage. Those always go through the normal gate.

Not every write needs the same ceremony

If every tiny edit needs an approval, people stop reading approvals. So writes now fall into three tiers, decided before anything runs:

• Full gate: anything destructive or anything that can’t be undone. Type the exact record count.
• Confirm: sensitive fields, batches over 100 records, and workflow changes. One approval, no count.
• Auto: small, reversible, non-sensitive changes. They apply immediately and hand back an undo command.

The limits live in a settings file per portal, and a portal’s settings can only add protection. They can add sensitive fields and tools that always need a human. They can’t remove the ones that ship with the plugin. Two things never auto-apply regardless: workflow changes, and anything a scheduled run or a multi-step loop produces. Those always wait for a person.

Where it stands

The plugin has 44 specialist agents and 79 tools. The test suite covers 1,182 cases, run on every change. The goal the project sets for itself is to finish in under a minute what takes about five minutes of clicking in HubSpot, with zero unapproved writes. That’s a target, not a measurement yet. I’ll report real numbers from real portals when I have them.

It’s open source under MIT, and it’s still a beta. If you run HubSpot, try it against a free developer test portal, never your live one, and tell me what breaks: github.com/promptmetrics/hubspot-claude.