Lead Routing Change Fixture Report

Compare two declared routing-rule versions before handing off a territory or queue change. Supply a baseline model, a candidate model and finite test fixtures. This Actor produces a reproducible report showing the owner each model selects, which rule wins, later matching rules shadowed on that fixture, owner changes and differences from your expected candidate owner.

The workflow is useful for revenue-operations administrators and consultants who already maintain synthetic routing examples or authorized exports. Re-run it when a declared rule order, territory condition or fallback changes, and keep the downloaded evidence beside your change review. This report tests only the literal models you supply. It does not connect to a CRM or reproduce live Salesforce, HubSpot, Flow, Apex or other automation.

Input

Use snapshotId for your review reference and fields for 1–20 unique literal attribute names. Field names start with a letter, followed by letters, digits, underscores, dots or hyphens, up to 64 characters. Dots are literal names rather than nested paths. Reserved prototype names are rejected. Use pseudonymous queue and fixture identifiers; names, email addresses and credentials are unnecessary.

Each baseline and candidate model requires version, fallbackOwnerId and rules. Each rule has ruleId, integer priority, ownerId, explicit unconditional and predicates. Smaller priority numbers run first. IDs and priorities must be unique within a model; array position does not define precedence. A predicate maps a declared field to a nonempty list of exact string values. Values within one field are alternatives; different fields are combined with AND. Case and whitespace are preserved. An unconditional rule has unconditional: true and empty predicates. A conditional rule has unconditional: false and at least one predicate. No regex, formulas, arbitrary code, numeric comparison or fuzzy matching is supported.

{
  "version": "candidate-v2",
  "fallbackOwnerId": "queue-general",
  "rules": [{
    "ruleId": "us-enterprise", "priority": 0,
    "ownerId": "queue-us-enterprise", "unconditional": false,
    "predicates": { "territory": ["US"], "segment": ["enterprise"] }
  }]
}

Provide fixtures as an array of unique rowId, attributes and optional expectedCandidateOwner. Alternatively, remove the array and provide nonempty fixturesCsv with optional fixtureColumns mapping. The mapping is {rowId: "Fixture", expectedCandidateOwner: "Expected", attributes: {territory: "Region", segment: "Segment"}}. Without mapping, headers are rowId, optional expectedCandidateOwner, and literal field names. If an attribute has one of those two metadata names, its canonical header is attribute:rowId or attribute:expectedCandidateOwner. CSV supports BOM and quoted values. Duplicate or unmapped headers, irregular rows and duplicate fixture IDs are rejected. Missing attribute columns represent missing evidence. Blank attribute cells represent exact empty strings; they are not missing. A blank expectation means no expectation was supplied. Header-only CSV and an explicit empty array produce a no-fixtures report.

Interpretation

The first definite matching rule wins only when no earlier rule is uncertain. If a missing field could change that winner, the owner and winning rule are unknown. Possible winner IDs, relevant missing fields and fallback possibility remain visible. A known false AND condition defeats another missing condition in the same rule. Missing conditions after a definite winner cannot change that winner. The report conservatively keeps a winning rule unknown even when its possible owners happen to coincide.

Shadow evidence applies to each supplied fixture only. A later definite match is called shadowed when the first winning rule is resolved. A rule with no definite matching fixture needs more test coverage; this does not prove that the rule is unreachable. An unchanged-owner conclusion applies only to supplied fixtures and does not establish coverage of all real leads. reviewRequired can remain true because of uncovered rules, changes, mismatches, uncertainty or an empty fixture set. Owner changes are evidence for review, not automatically mistakes. Expected-owner mismatches compare your expectation with the declared candidate model, not with a CRM's live behavior.

Results and limits

One dataset item contains the complete report, all supplied fixtures, both normalized models, comparisons, findings and rule coverage. Download full JSON, flat comparison CSV, findings CSV and standalone HTML. The HTML includes models and fixture evidence and has no external scripts. Download it using its attachment link and open it locally. CSV neutralizes spreadsheet formula prefixes; JSON preserves exact identifiers.

Limits are 100 rules per model, 20 fields, 2,000 fixtures, 4 MB total input JSON and 20,000 matched or unknown rule occurrences across both models. JSON must be under 8 MB and each export under 9 MB. Dense matching models or long identifiers can require smaller batches even within the input limits. All size and evidence caps are checked before a report event is charged.

A completed report costs $0.25, including platform usage. Invalid input, insufficient budget or an output-limit rejection produces no report event. A new run is billable again. Resuming the same run checks saved input and report integrity and restores exports without adding a second dataset item or report event. Interrupted export writes can leave partial files; recovery rewrites them before publishing the report. Apify stores cloud input and outputs, so use authorized data and follow your own retention policy. No external APIs, paid models, CRM credentials or writes are used.