Most lead routing audits check whether the rules look right. That is the wrong question. A clean assignment-rule screen tells you what the system is supposed to do; it says nothing about what happened to the 4,000 real submissions that moved through it last quarter. The gap between those two things is where good leads quietly go missing, and it is exactly where a proper lead routing audit earns its keep.
The distinction matters because the failure you are hunting almost never shows up in the configuration. The rule is active, the round robin is balanced on paper, the owner field is populated. And yet a high-intent demo request sat in a default queue for two days, or landed on a rep who left in March, or created a second duplicate record that killed the notification. None of that is visible in the rulebook. It is only visible in the transaction.
Direct answer — what is a lead routing audit?
A lead routing audit is a controlled check of both the configuration and real transactions in your lead flow, run to confirm that each eligible submission becomes exactly one correctly owned, accepted and worked record inside the time limits you set. It inspects the active rules, then traces known test submissions through all 13 handoffs from form to first sales action, and it publishes the exact definitions used for lost, delayed, wrong-owner, duplicate, unmatched and unworked leads.
Key Takeaways
- An audit needs two proofs, not one: a configuration audit shows intended logic, transaction testing shows observed behaviour. Neither one substitutes for the other.
- Reconcile every adjacent handoff, not just form-to-CRM. A final CRM record can hide partial field loss, a fallback route, a late assignment or a missing notification.
- A default owner is not proof the system worked. Report fallback rate and primary-match success as separate numbers.
- Missing logs do not prove nothing failed. Log retention caps and daily limits mean absent evidence is an observability gap, not an all-clear.
- The routing thresholds circulating online are not benchmarks. None publish a denominator. Compute your own rates with the population and clock attached.
- The free workbook below carries the full 13-stage control framework, 36 test cases, every formula and a 39-source evidence ledger.
What a lead routing audit has to prove
A lead routing audit is the disciplined answer to one question: did each eligible submission become one correct, accepted and worked record, and is there enough evidence to find the first failed handoff when it did not? Everything in the method serves that question. Break it into five things the audit must actually prove, because “the routing works” is too vague to test.
Continuity means one authoritative submission produces one usable record with no silent field loss. Correctness means the lead reaches the owner your frozen rules say it should, or an approved fallback that is measured as a fallback. Timeliness means each stage completes inside a published SLA. Workability means a human accepts the lead and takes a real first action, not an automated acknowledgement. And evidence completeness means you can actually prove the other four for any given lead, because an audit you cannot reconstruct is an opinion.
The reason most checklists fall short is that they only ever inspect one side of the ledger. They read the rules. They never trace a transaction. The two produce different evidence, and you need both columns filled in before you can call a route healthy.
Configuration evidence versus transaction evidence
| What you are checking | Configuration evidence (what the rules say) | Transaction evidence (what one real lead did) |
|---|---|---|
| Ownership | An assignment rule exists and names the expected owner | Owner history shows the actual owner written at assignment time, matched against the frozen oracle |
| Speed | An SLA is defined in policy | Assignment and first-action timestamps, in UTC, measured against that SLA |
| Deduplication | A duplicate rule is switched on | One logical submission produced one live record, or a documented merge |
| Notification | A workflow is set to alert the owner | A delivered notification or a recorded queue-visibility event |
| Fallback | A default queue is configured | The route log shows whether the primary rule fired or the fallback caught the lead |
Read that table as a job description. Every row where you can fill the left column but not the right is a row where you are guessing. The rest of this guide is how you fill the right column, and the end-to-end routing system this audit inspects is documented separately if you need the model before you test it.
Why a clean assignment-rule screen proves nothing
Assignment rules are necessary and nowhere near sufficient, and the platform documentation is blunt about why. The same rulebook produces different outcomes depending on the channel a lead entered through, whether a duplicate rule blocked the write, what order your automation ran in, and whether logging was even switched on to record it.
Salesforce is explicit that a web lead with no matching assignment entry falls to the configured default lead owner, which means a fully populated owner field can hide a total match failure. It also documents a harder edge: the Web-to-Case and Web-to-Lead pending request queue has a limit of 50,000 combined requests, and once an org hits it, additional requests are rejected and not queued, with the admin emailed for only the first five. Those submissions never become records. No assignment-rule screen will ever show you that, because the lead never reached the rule.
IMPORTANT
A populated owner field is the single most misleading signal in a routing audit. It can mean the rule fired correctly, or it can mean the rule matched nothing and a default owner caught the lead. Those are opposite outcomes that look identical in a list view. Only the route log tells them apart.
This is why “misrouted leads” is a category you have to define before you can count it. A lead sitting with the default owner is not necessarily misrouted, and a lead with a valid owner is not necessarily routed correctly. Both claims need the transaction trace behind them. The same logic applies to the qualification step, where the boundary between a marketing-qualified and a sales-qualified lead is a rule version you have to freeze before you test it, or you will attribute a scoring change to a routing defect.
The 13-stage chain from submission to first action
A routing audit reconciles stage to stage, not just form to CRM, because a final record can look perfect while three handoffs behind it leaked. The chain below is platform-neutral: it holds whether you run Salesforce, HubSpot, a middleware recipe or all three. Each stage has one job to prove and one primary piece of evidence that proves it.
| # | Stage | What it must prove | Evidence that proves it | Most common failure |
|---|---|---|---|---|
| 1 | Form submission | One user action generated one authoritative submission event | Form submission export, server receipt, network trace | Tracking script blocked; intake limit reached |
| 2 | Field capture | Required routing fields were captured without silent coercion | Submission payload versus stored property | Field exists in the submission but not on the record |
| 3 | Consent | Required consent state and text version were recorded | Consent property, form version, text snapshot | Old form still serving pre-update consent copy |
| 4 | Enrichment | Enrichment returned data or invoked a safe fallback | Provider request log, match or no-match status | Timeout or no-match silently blocks the route |
| 5 | Validation | Invalid records are rejected or quarantined, not lost | Validation error, workflow branch, quarantine queue | Invalid record disappears with no quarantine |
| 6 | Deduplication | One identity produces one intended live record | Duplicate-rule result, matching evidence, merge history | Concurrent submits create two live records |
| 7 | Account matching | The lead links to the correct account or a marked unmatched state | Association history, domain match trace, candidate list | New domain or subsidiary misses the parent account |
| 8 | Qualification | The outcome matches the frozen rule and keeps reason codes | Score history, workflow branch, reason field | Missing enrichment field feeds the score |
| 9 | Routing decision | The evaluated route and fallback are deterministic | Workflow, Flow, Apex or router branch log | Overlapping criteria; no rule match |
| 10 | Owner assignment | Exactly one valid owner was written, matching the oracle | Assignment record, owner history, queue membership | Inactive owner; API path skips the rule |
| 11 | Notification | The owner received or could reliably discover the lead | Email or event record, task creation, Slack log | Notification suppressed by channel or API limit |
| 12 | Acceptance | Responsibility was explicitly accepted where required | Status change, queue claim, task completion | Assignment ignored; no acceptance event fires |
| 13 | First action | A qualifying human action occurred and links to the lead | CRM activity, dialer or email event, meeting record | Only an automated acknowledgement, no human touch |
Stages 1 to 6 are capture and identity. Stages 7 to 10 are routing and ownership. Stages 11 to 13 are workability, and they are where unworked leads hide: a lead can be assigned, notified and still never worked, which is why the chain does not end at owner assignment. It ends when a human takes responsibility and acts. That final handoff is the whole reason sales acceptance is a measured event and not an assumption.
Collect the evidence before you run a single test
Evidence is the part teams skip, and it is the part that makes an audit defensible instead of anecdotal. Before you submit a single test lead, decide how you will prove what happened to it. The unit that makes this possible is a correlation ID: a unique value you can carry or cross-reference across the form, the middleware, the CRM record and the activity log, so that “this submission” and “this record” are provably the same thing.
For every tested transaction, plan to capture the submission ID and CRM IDs, the active rule and workflow versions, UTC timestamps at each handoff, the field values and their history, the assignment and notification records, the acceptance event and the first action. Store timestamps in UTC and apply any business-hours transformation on top, never the reverse. If you capture local time first you cannot reliably compare a lead that arrived in London with one that arrived in Denver.
Your logs expire, so export them inside the window
The evidence system has its own failure modes, and they are on documented timers. Missing logs are frequently misread as “nothing failed,” when the honest reading is “we can no longer tell.” The caps below are real, current and easy to breach during a busy launch, which is precisely when you most need the record.
| Platform and evidence | The documented limit | Why it bites during an audit |
|---|---|---|
| HubSpot workflow enrollment history | Stored 6 months; after 100,000 successful execution logs in a day, success and info logs stop while error logs continue | A high-volume launch day can stop recording successes, so a “missing” success log may just mean you hit the cap |
| HubSpot property history export | Up to 45 revisions for contacts, 20 for company, deal, ticket and custom objects; timestamps in UTC | A high-churn owner field can push older assignment changes past the retention limit |
| Zapier autoreplay | Retries an errored step up to 5 times; Filter and Paths steps are never replayed; 60-day replay window | A retry can recover, delay or duplicate a lead, so replay history must be read alongside idempotency |
| Salesforce debug logs | Only capture execution when logging is configured and retained | The absence of a debug log is not evidence that no failure occurred |
The practical rule: export incident evidence while the transaction is still inside every one of these windows. A dashboard count that you did not screenshot or export is not evidence three weeks later. This is the same discipline that makes form payload capture worth validating at the source, because once the field is gone from the record, the submission export is the only proof it was ever there.
Run the configuration audit first
The configuration audit is the cheaper of the two proofs, so run it first and let it tell you where to point the expensive one. Inspect the active rules and their order, the field mappings, the queue membership and permissions, the notifications, the fallbacks, the retry contracts and, critically, the version of every workflow and rule in the path. Version capture is not optional: routing outcomes change when a Flow is edited or an owner list is reset, and without the version you cannot attribute an outcome to the logic that actually ran.
Pay special attention to the entry channels, because they do not behave alike. A lead created through a Salesforce API path can bypass the assignment rule unless the call sets the rule header, while the same org’s web form invokes it automatically. HubSpot’s non-native forms capture and map differently from native ones, which is the mechanism behind hidden fields that fail to store their UTM data. Each production channel needs its own test, because “the rule is correct” is a claim about the rule, not about the six different doors leads walk through.
Run transaction-level tests
This is the half nobody else does, and it is where the citations live. A transaction test submits a known input with a known expected outcome, then follows it through every stage and checks reality against expectation. To do it you need two things: a frozen routing oracle and a synthetic dataset. The oracle is the table of inputs, rule versions and expected routes you freeze before testing, so that “wrong owner” has a fixed definition to be wrong against. The synthetic data uses reserved domains and invented identities, never real personal data pushed into production purely to test.
Workflow · 30 min
How to trace one lead from form to first action
A single end-to-end trace is the smallest unit of a routing audit and the fastest way to find a broken handoff. Repeat it across 10 to 20 recent leads to move from anecdote to pattern.
Freeze the oracle
Record the active rule and workflow versions and the owner you expect this lead to land on, before you submit anything. This is what “correct” is measured against.
Submit one synthetic lead
Use a reserved domain, a unique correlation ID and a real production entry channel. Test each channel separately, because API and web paths can behave differently.
Follow the correlation ID across systems
Pull the form export, integration run log, CRM record, owner history, notification, acceptance event and first activity, and confirm they all reference the same submission.
Stamp every handoff in UTC
Capture the completion time of each of the 13 stages so you can localise which handoff lost the time, then apply business-hours rules on top if needed.
Compare actual owner to the frozen oracle
A match on a fallback owner is not a match on the primary route. Record which one fired, so fallback success and primary-match success stay separate numbers.
Preserve the evidence before it expires
Export the logs with retention caps, workflow history and debug logs, while the transaction is still inside its window. A missing log later proves nothing either way.
Four test categories, and the coverage they owe you
A test pack that only submits clean leads audits the happy path and nothing else. Real routing breaks at the edges, so every critical stage owes you four kinds of test. Positive tests confirm a valid lead routes as intended. Negative tests confirm an invalid lead is rejected or quarantined, not silently dropped, which only holds when your validation criteria are explicit enough to fail a record on purpose. Boundary tests probe the exact threshold, the employee count of 49 against 50 against 51 across a territory split. Exception tests break a dependency: an inactive owner, a provider timeout, a held integration run, a replay after a partial success.
| Critical stage | Positive | Negative | Boundary | Exception |
|---|---|---|---|---|
| Capture and validation | All routing fields present | Required field omitted | Max length, Unicode, whitespace | Tracking script blocked |
| Deduplication | New unique identity | Known duplicate resubmits | Two near-simultaneous submits | Channel bypasses the duplicate rule |
| Account matching | Unique domain to named account | No account candidate | Parent and subsidiary both match | Account merge or domain change |
| Qualification and routing | Standard territory and score | Clearly disqualified input | Score one under, at, one over threshold | Missing enrichment field feeds the score |
| Owner assignment | Active expected owner | Ineligible owner | Round-robin reset or capacity edge | Inactive user; API skips the rule |
The downloadable workbook carries 36 deterministic cases mapped to this matrix, including the concurrency, replay and version-change scenarios that generic checklists never mention. Building this coverage is the same test discipline you would apply when you QA campaign links before a launch, extended from the URL to the entire post-submission chain.
Classify the failure before you fix it
Naming the failure precisely is half the remediation, because “leads are getting lost” sends five teams chasing five different problems. Six classes cover the field, and they are not interchangeable: a lost lead, a delayed lead, a misassigned lead, a duplicate, an unmatched lead and an unworked lead each have a different evidence signature and a different owner. Collapsing them into “lead leakage” is how a routing problem gets misdiagnosed as a rep-performance problem.
| Class | What it looks like | Evidence signature | Typical severity |
|---|---|---|---|
| Lost | Submission exists, but no CRM record by the capture SLA, or a record that never reaches a route decision | Submission ID with no CRM ID, or a CRM record with no workflow or route event | Critical |
| Delayed | Assignment, notification or first action lands after its SLA | Stage timestamps show the delay concentrated at one handoff | High |
| Misassigned | Actual owner differs from the frozen expected owner, or a fallback caught a lead that should have matched | Owner history against the route oracle and active rule version | High |
| Duplicate | One submission creates multiple live records, or triggers duplicate outreach | One correlation ID mapped to multiple CRM IDs or activity IDs | High |
| Unmatched | No account or territory match; if no approved fallback exists, the lead dead-ends | Unmatched reason with no fallback record | Medium, or Critical with no fallback |
| Unworked | Assigned and notified, but not accepted or not actioned by SLA | Assignment and notification present, acceptance or first activity absent | High |
Severity is driven by intent tier, affected reach, duration, recoverability and any compliance exposure, never by a revenue multiplier you cannot defend. A single lost enterprise demo request outranks fifty delayed newsletter signups, and the severity column has to reflect that judgement rather than a raw count.
Calculate routing metrics without hiding the lost leads
A rate is only reproducible when its denominator is published, and this is where most routing numbers quietly cheat. If you calculate an average assignment time only over the leads that got assigned, you have hidden every lead that never did behind survivor bias. A healthy-looking median speed-to-lead figure can sit directly on top of a stack of leads that were never responded to at all, which is why a response-time metric is only trustworthy once the routing audit has confirmed the denominator underneath it. The fix is to publish, for every metric, the eligible population, the logical identity unit, the start and end events, the audit cut-off, the timezone and the clock basis, then report completion and breach rates beside every percentile.
| Metric | Formula | The denominator rule that keeps it honest |
|---|---|---|
| Routing success rate | Eligible submissions that create one usable record, get the expected owner and meet the assignment SLA, over all eligible submissions | A missing owner or missing assignment timestamp is not a success; score approved fallback separately |
| Lost rate | Eligible submissions with no usable record by the capture SLA and no recovery record, over all eligible submissions | Use the authoritative intake event as the denominator, never CRM-created records |
| Unmatched rate | Records reaching the match stage with no primary match, over records reaching that stage | Split approved-fallback unmatched from unhandled unmatched |
| Duplicate rate | Logical submissions linked to more than one live record or route execution, over eligible logical submissions | Publish the dedup unit and how intentional resubmissions are treated |
| Wrong-owner rate | Assigned records whose actual owner is not the frozen expected owner, over assigned records with a determinable expected owner | Use owner history at assignment time; do not count later authorised reassignment as a routing error |
| SLA breach rate | Records whose endpoint is missing at cut-off or whose latency exceeds SLA, over all records subject to that clock | Publish wall-clock or business-clock rules, timezone, holidays and cut-off |
| Unaccepted-lead rate | Leads requiring acceptance with none by cut-off, over all leads requiring acceptance | Do not apply where the process has no acceptance event at all |
P(n) latency = nearest-rank value at rank ⌈p × n⌉ of completed finite latenciesSort the completed, finite latencies ascending and take the observation at rank ceiling of p times n. Report the completion rate and the breach rate next to P50, P90 and P95, and let missing endpoints count as breaches rather than assigning them a fake infinite latency. A percentile that silently drops the leads that never completed is worse than no percentile, because it looks rigorous while hiding the exact failures you are auditing for.
Score the audit
A score turns twenty separate checks into one defensible number, provided every weight is on the table. The IVRIS model marks each control Pass at 2, Warning at 1 or Fail at 0, multiplies the halved status by a published weight, and sums the result. Pass is 90 to 100, Warning is 75 to just under 90, and anything under 75, or any critical control that fails outright, drops the whole audit to Fail through a critical override. This is an operating-control score you set for your own system, not an industry benchmark, and that distinction is deliberate.
| Pillar | Representative controls | Weight | Critical override |
|---|---|---|---|
| Delivery and capture continuity | Submission reconciliation, required-field capture, consent evidence | 20 | Yes |
| Identity and data integrity | Validation, duplicate disposition, account matching, enrichment fallback | 20 | Partial |
| Routing correctness | Route determinism, expected owner equals actual, approved fallback, inactive-owner handling | 25 | Yes |
| Timeliness and workability | Assignment SLA, notification, acceptance SLA, first-action SLA | 20 | Partial |
| Observability and change control | Correlation IDs, version capture, evidence retention, regression schedule | 15 | Partial |
A critical override fires on the failures you cannot buy back with strong performance elsewhere: a high-intent submission with no usable record, no owner and no recovery path, an absent required consent record, a materially wrong owner, or a critical path you simply cannot evidence. Those cap the result at Fail no matter how clean the rest of the audit looks, because a routing system that loses one enterprise lead and handles a thousand newsletter signups perfectly is still failing at its actual job.
Platform failure modes to test
The framework is platform-neutral, but the failures are specific, and you have to test the ones your stack actually produces. The compatibility matrix in the workbook covers these channel by channel; here are the ones worth committing to memory.
Salesforce failure modes
Test the Web-to-Lead pending queue limit, the duplicate rule that can block a web submission from ever creating a record, and the default lead owner that catches an unmatched lead and masks the miss. Check whether an API path sets the assignment rule header, because an API transaction only invokes the rule when the header tells it to. Confirm the run order of your record-triggered Flows, and remember that standard field history tracks a limited set of fields, so routing-critical fields need deliberate coverage or a separate audit capability.
HubSpot failure modes
Test form capture dependencies and partial submissions on non-native forms, mapping gaps where a field is captured but not stored, consent-copy drift on old form versions, and enrichment eligibility, since contact enrichment needs a business email and company enrichment needs a domain. Watch the rotation reset: HubSpot’s owner rotation counts are specific to each action and can reset when owners change, so round-robin fairness cannot be judged on total records owned. Then account for the workflow-log and property-history caps from the retention table above, and the Salesforce sync errors that can stop individual records moving between the two systems while the connector still shows as installed. The behavioural gap between the two platforms is real enough that it shapes any HubSpot and Salesforce comparison at the operations level.
Integration and webhook failure modes
Middleware turns a loss problem into a delay or duplicate problem, and the semantics differ by tool, so never generalise one vendor’s retry behaviour to another. Test held runs, retries and replay, version retention, and idempotency, because a replay can complete a missing step or repeat a completed one depending on whether your downstream action is idempotent. If you are choosing between platforms on exactly these behaviours, the differences across n8n, Make and Zapier are precisely the retry and replay semantics your audit has to pin down per connector.
Why the routing thresholds you find online are not benchmarks
Search “lead routing audit” and you will meet a confident set of numbers: assignment-to-first-touch under ten minutes, distribution parity within ten percent, a default-owner rate under five percent, an SLA breach rate under five percent. They read like industry benchmarks. They are not. None of the pages publishing them attach a sample, a population, a denominator or a date, and a threshold with no denominator is an opinion in a numeric costume.
This is not a technicality. A “5% default-owner rate” means nothing until you know whether the denominator is all submissions, all created records or all assigned records, and those three produce wildly different numbers from the same system. Vendor benchmark tables have the opposite problem: they are real data, but they are proprietary aggregates drawn from one platform’s customer base, which makes them a performance envelope for that population, not a market norm you can hold your own routing to.
PRO TIP
When you cite a routing statistic, cite the denominator with it or do not cite it at all. “Our default-owner rate was 4%, measured as unmatched-to-default assignments over all eligible submissions in June, UTC” is defensible. “Industry best practice is under 5%” is not, because nobody can tell you 5% of what.
So IVRIS publishes no competing threshold. The honest contribution is the method to compute your own rate with the population attached, plus the plain statement that the circulating numbers are not benchmarks. Use the decision framework below to pick the right depth of check for the situation, rather than reaching for a number someone else could not defend.
Use a configuration audit when you have changed a rule, a mapping or an owner list and want to confirm the intended logic before traffic hits it. Run a transaction test when a specific lead or channel is behaving oddly and you need to prove what actually happened, not what should have. Escalate to the full 13-stage audit on a launch, a platform migration, a spike in any failure class, or on the recurring cadence, when the cost of a hidden leak outweighs the cost of the check. The scoring rules that decide qualification deserve the same version-frozen treatment, since a scoring edit and a routing edit produce identical-looking symptoms downstream.
How often to audit
Routing degrades quietly between audits, so the cadence matters as much as the method. Tie audits to both a calendar and a set of events, because the calendar catches drift and the events catch the specific changes that break routes.
| When | Minimum scope | Owner |
|---|---|---|
| Before every launch or deployment | Full configuration audit; all critical-path positive cases; changed-rule boundary cases | Launch owner and CRM admin |
| Immediately after release (smoke test) | One positive test per production route, plus fallback, duplicate and notification | Release owner |
| Within 24 hours of release | Submission-to-CRM counts, unowned, fallback, sync errors, assignment latency | RevOps |
| Weekly | Lost, unowned, fallback and wrong-owner samples, SLA breaches, connector errors | Sales or Marketing Ops |
| Monthly | Critical routes, owner roster, queue membership, integration limits, selected negative and exception tests | CRM admin and RevOps |
| Quarterly | All 13 stages, configuration plus a transaction sample, scoring and evidence retention | RevOps owner |
| On any owner roster change | Owner eligibility, queues, round robin, named accounts, fallback | Sales Ops |
| On any platform or integration change | Affected channel, retry, mapping, logging and idempotency cases | System owner |
The event triggers are the ones that save you: a rep leaves, a package updates, a connector changes its API version, a consent policy changes, or any failure class spikes. Each one should fire a targeted regression before the next scheduled audit, not after. Wiring this cadence into your operating rhythm is a natural extension of the operating discipline RevOps already owns: defined once, enforced on every intake, and re-checked whenever the system changes underneath it.
Download the lead routing audit workbook
Everything in this guide is built into a free, inspectable workbook so you can run the audit rather than just read about it. It is deliberately public: no gate, no email wall, and a source ledger you can check line by line.
The workbook carries a Read Me and the 13-stage control framework, 36 test cases across positive, negative, boundary and exception coverage, a synthetic test-data template with a frozen routing oracle, a transaction run log with live formulas that compute every rate as you enter results, an evidence log with retention deadlines, a failure log with the six-class taxonomy, a metrics sheet, the 20-control scoring model with all weights shown, the audit cadence, a full 39-source evidence ledger with direct URLs and transparency scores, a platform compatibility matrix and a revision log. The test-case library and the source ledger also ship as standalone CSV files.
If your team would rather have the form-to-CRM evidence instrumented and the transaction tests run for you, that is work IVRIS can help with; the routing-audit and implementation options are here once you have the method in hand. The method comes first, on purpose. You should be able to reproduce every number on this page before anyone offers to run it for you.
Suggested citation: IVRIS Tech (2026), “Lead Routing Audit Checklist,” https://ivristech.com/lead-routing-audit/, reviewed 23 July 2026.
Frequently Asked Questions
A configuration audit inspects the rules, order, mappings and owners to prove intended logic. Transaction testing submits known leads and traces them through every stage to prove observed behaviour. Rules can be correct while real submissions still fail, so you need both proofs, not one.
A correlation ID linking the submission to one CRM record, owner history showing the actual owner matched against a frozen oracle, UTC timestamps at each handoff, a delivered notification, an acceptance event and a first human action. A populated owner field alone is not proof; it can hide a default-owner fallback.
No. A default owner can prevent an unowned lead while still signalling that the primary match failed. Salesforce assigns a default lead owner when no assignment rule matches. Report fallback rate and primary-match success as separate numbers, or a match failure will read as a healthy assignment.
No. HubSpot caps successful workflow logs at 100,000 per day and retains history for six months; Salesforce debug logs only exist when logging is configured. A missing log is an observability gap, not an all-clear. Treat absent required evidence as a Warning or Fail, never as a silent pass.
Use synthetic identities on reserved domains such as example.com, each with a unique correlation ID and a frozen expected outcome. Never push real personal data into production purely to test. The workbook’s test-data sheet gives you a template and a routing oracle to define expected results in advance.
Methodology, sources and revision history
This page is built from public third-party documentation and official product help pages. IVRIS did not conduct the underlying studies or write the platform documentation, and each organisation retains ownership of its own material. What IVRIS contributes is the synthesis layer: the 13-stage control framework, the six-class failure taxonomy, the metric definitions and denominators, the 20-control scoring model, the 36-case test library and the transparency scoring applied to every source.
Every platform limit on this page carries its original source and was verified live on 23 July 2026: the Salesforce 50,000 pending-queue limit, the HubSpot 100,000 daily successful-log cap and six-month retention, the HubSpot 45-revision and 20-revision property-history limits, and the Zapier five-retry, 60-day replay window. Figures measured against different denominators or endpoints are never averaged together, and where no defensible public benchmark exists, this page says so rather than inventing one. The full 39-source ledger, with direct URLs and transparency scores, ships inside the downloadable workbook.
Last reviewed: 23 July 2026. Revision history: 23 July 2026, first publication. Next scheduled review: on any material change to Salesforce, HubSpot, Zapier or Workato routing, form, enrichment, deduplication or integration documentation, and no later than a quarterly re-check.
