How to Audit CRM Automation: Conflicts, Dead Workflows and Silent Failures

What is a CRM automation audit?

A CRM automation audit is a review of every workflow, flow, sequence and integration automation in your system, checking what each one does, whether it still matches the business, and how they interact with each other. The interactions are the important part. Individual workflows usually look fine on their own. The damage comes from two of them changing the same field, or one sending an email the other was meant to suppress.

This guide is narrower than our general CRM audit walkthrough, which covers data, lifecycle, reporting and governance as well. Here we only look at automation, and go further into it. It’s the review to run when you have dozens or hundreds of workflows, no one person is sure what they all do, and odd things keep happening to records.

Signs your automation needs auditing

You probably don’t need a formal audit to know. These are the symptoms people tend to describe before one:

• A contact’s owner or lifecycle stage changes and no one can say why.
• Customers receive emails meant for prospects, or the same email twice.
• Someone wants to turn off an old workflow but is afraid to, because it isn’t clear what depends on it.
• Notifications go to people who’ve left, or to a shared inbox that isn’t monitored.
• The workflow list has names like “Copy of nurture v2 FINAL (do not use)”.

That last one sounds like a joke. It’s far more common than anyone admits.

Step 1: Build the inventory

List every automation in one spreadsheet. Not just native CRM workflows, but also email platform flows, sales sequences, integration-platform automations in Zapier, Make or n8n, webhooks, and anything a native integration does on its own, such as an ecommerce connector that sets properties on sync.

For each one, record:

• Name and platform
• Status: on, off, draft
• Trigger type: form submission, property change, list or segment membership, event, schedule, webhook
• Enrollment criteria, in plain English
• Re-enrollment: can a record go through it more than once, and on what condition
• Exit or goal criteria: what removes a record early
• Actions: emails sent, fields set, tasks or notifications created, external calls made
• Fields written: every property this automation can change
• Enrollments in the last 90 days
• Owner and last edited date
• Purpose: why it exists, if anyone knows

The “fields written” column is the one people skip and the one you’ll need most. Take the time to open each workflow and list every field it touches, including fields set inside branches.

Step 2: Classify what you’ve found

Sort every automation into one of five groups:

1. Working and needed. Clear purpose, enrolling records, doing what it should.
2. On but idle. No enrollments in months. Either the trigger can no longer be met (a form was deleted, a property value was renamed) or the business stopped doing the thing.
3. Broken. Enrolling records but erroring, sending to missing addresses, or referencing deleted properties or users.
4. Duplicated. Two or more doing the same job, often an old version and its replacement both left on.
5. Unknown. No one on the current team can explain it. These need the most care.

Expect the unknown group to be bigger than you’d like. That’s normal, and it’s useful information.

Step 3: Map which automations write to each field

Now flip the inventory around. Take your important fields (lifecycle stage, owner, lead status, lead score, customer flags, segment or tier properties, consent fields) and list, for each one, every automation and integration that can write to it.

This is where most of the real findings come from. For example:

When more than one thing writes to a field, decide which one is the authority and make the others either defer to it or stop writing. Sometimes the answer is a single “controller” workflow per critical field, with everything else setting an intermediate property that the controller reads.

Step 4: Check triggers, re-enrollment and exits

Go through the working and broken groups and check the logic, not just the intent.

Triggers. Does the enrollment criteria match the written purpose? A welcome workflow triggered by “contact created” will also catch every import, every integration-created record and every sales rep adding a contact by hand.

Re-enrollment. Re-enrollment on a property change is the most common cause of repeated emails and owner flip-flopping. Check which properties allow re-enrollment, and whether any of those properties are written by another automation.

Exits and suppression. Every marketing automation should have clear exits: became a customer, booked a meeting, unsubscribed, deal created. Look for acquisition emails without a customer exclusion, and sales sequences that don’t check opt-out status.

Branch logic. If/then branches often have a default “none met” path that does something unexpected, like assigning to whoever built the workflow.

Timing. Delays that ignore weekends and time zones. A “follow up in 24 hours” task created at 4pm on Friday lands at 4pm on Saturday. A send window set to the builder’s time zone means overseas contacts get emails at 3am.

Step 5: Review automation that lives outside the CRM

Integration-platform automations need their own look, because they fail differently. A native workflow usually shows an error in the CRM. A Zap or Make scenario that fails often just stops, silently, unless error alerts were set up.

For each one, check:

• whose account it runs under, and whether that person still works with you
• whether it has error handling or alerts, and where they go
• the run history: failures, partial runs, and how many records were skipped
• whether it creates records or updates existing ones, and how it matches them
• whether a native integration now does the same job

Webhooks deserve the same treatment. Find out what happens when the receiving endpoint is down. If the answer is “the data is lost”, note it. Our pages on Zapier, Make and n8n cover the platform-specific quirks.

Step 6: Test with real records

Settings tell you what should happen. Test records tell you what does. Create a small set of test contacts that represent your main scenarios and push them through:

• a brand-new inbound lead from your main form
• a lead whose company already exists in the CRM with an owner
• an existing customer who fills out a marketing form
• a contact who unsubscribed and then submits a form
• a lead from a region or segment with special routing
• a record imported in bulk, the way your team usually imports

For each one, record which automations enrolled, what fields changed and in what order, what emails or notifications went out, and the final state. Use a recognizable naming pattern for test records so you can find and remove them later, and send test emails to an address you control.

The existing-customer test is worth singling out. It’s the one most likely to reveal an email or field change that should never happen to someone who already pays you.

A workflow QA checklist gives you a repeatable structure for these tests, which is also useful every time someone builds a new workflow.

Step 7: Decide to keep, fix, merge or retire

For each automation, make one of four decisions and record the reason.

Keep the ones that work, but add a clear name and a description of purpose if they lack one.

Fix the ones with logic problems, after deciding who owns each critical field.

Merge duplicates into one version, and check that anything referencing the old one is updated.

Retire idle and unneeded ones. Don’t delete straight away. Turn them off, note the date, and wait a few weeks to see if anything breaks or anyone complains. Then delete or archive. For the unknown group, turning off and watching is often the only way to learn what they did.

Make the changes in batches and in priority order: anything sending wrong messages to customers or ignoring opt-outs first, then anything corrupting critical fields, then cleanup and naming.

Document as you go

The audit loses most of its value if, a year from now, the reasons for each change are gone. At minimum, keep the inventory spreadsheet as a living document, add a purpose line to every workflow’s description, and adopt a naming convention that shows team, purpose and object, for example “MKT | Nurture | Contact | Webinar follow-up”.

New automations should be specified before they’re built. A short automation requirements template covering trigger, conditions, actions, fields written and exits prevents most of the conflicts this audit finds.

How often should you audit CRM automation?

A full automation audit once a year is reasonable for most teams, with a lighter quarterly check of idle workflows, error logs and integration run history. Also run one after any major change: a migration, a new sales process, a new integration, or a team member who built most of the automation leaving.

If you’d like someone else to run this review, our CRM Workflow Audit follows the same steps and ends with a prioritized fix list. For HubSpot specifically, see our HubSpot workflow audit guide.