Skip to content
Book a call
Menu

Routing test lab

Synthetic reference

Who gets the lead? Check the rule first.

Inspect six sample records before defining your HubSpot routing. See which owner is proposed, which contact is reused and which records stop for review. Fictional records, run in your browser. Nothing is written to HubSpot.

Try the six scenariosInspect the policy
Check / Resolve / RouteSynthetic reference
Check / Resolve / RouteA routing decision should have a named owner or a specific exception reason.01Check fit02Resolve therecord03Propose theaction
Check / Resolve / RouteA routing decision should have a named owner or a specific exception reason.01Check fit02Resolve therecord03Propose theaction
A routing decision should have a named owner or a specific exception reason.
  1. Check fitApply agreed eligibility criteria.
  2. Resolve the recordCheck identity and existing ownership.
  3. Propose the actionName an owner or hold with a reason.

Select a record

Pick a record and see the routing decision

The sample policy checks eligibility, identity, existing ownership, territory and owner availability in that order.

The net-new result is shown below. All six results are available in the acceptance matrix on this page. Enable JavaScript to select the other records here.

Input record

Policy 1.0.0

Select a fictional record. The result shows the first terminal rule and the checks that came before it.

View selected decision

01 / Net-new

A target account, one territory and an available sales owner.

Input ID
SYN-IN-001
Fictional email
buyer@northstar.example
Target fit
Eligible under the sample criteria
Contact match
No contact match supplied
Relationship
No customer relationship supplied
Customer owner
None supplied
Territory
Verified company region: EU

Local decision / No CRM write

Owner proposed

Sales EU 01

One agreed territory maps to one active owner under this sample policy.

Contact action
New contact proposed
Destination record
No ID yet
Terminal rule
R07
Reason code
TERRITORY_OWNER

Required next step

Implement the proposed action, then verify the destination contact and owner. The simulator has not written to HubSpot.

Decision trace

  1. R01

    EligibilityPass

    Target account and buying role match the agreed criteria.

  2. R02

    IdentityPass

    No existing contact match was supplied.

  3. R03

    Customer ownershipNot applicable

    The supplied record is not an existing customer.

  4. R04

    Existing contactNot applicable

    No matched contact needs to be reused.

  5. R05

    TerritoryPass

    One agreed territory: EU.

  6. R06

    Owner availabilityPass

    Sales EU 01 is active in the sample registry.

  7. R07

    AssignmentTerminal decision

    Propose Sales EU 01; propose a new contact.

The records, owners and IDs are fictional. This lab evaluates a sample policy locally. It does not search HubSpot, verify paid seats or perform CRM actions. Target fit is not permission to send outreach.

Policy order

The next rule depends on the last one

Built by AGI Technologies as an independent simulator for HubSpot routing.

An existing customer can retain its relationship owner before new-business territory rules run. Ambiguous identity or missing ownership stops the decision.

An explicit routing policySynthetic reference
Five ordered routing checks: eligibility, identity, existing ownership, territory and assignment. Each check either continues, retains an owner, excludes the record or holds it with an exception reason.
This shows the lab's own sample policy. Your HubSpot portal follows the routing rules you configure. A terminal result is a proposed action until it is implemented and verified in the CRM.
  1. Check eligibility and identityExclude an ineligible record. Hold multiple matches.
  2. Protect existing ownershipRetain a valid customer or contact owner.
  3. Require a clear assignmentOne territory and one active owner, otherwise hold.

Acceptance matrix

The final outcome for each sample record

These six outcomes come from running the lab’s rules on the fictional records.

Every record has a terminal state.
Synthetic inputTerminal decisionOwner or exceptionRecord action
01 / Net-newASSIGNED / R07Sales EU 01, one agreed territory and one active ownerPropose a new contact. No CRM write.
02 / Existing customerPRESERVED / R03Account team 02, active relationship owner retainedReuse SYN-CONTACT-020. No CRM write.
03 / Duplicate inputMATCHED / R04Sales EU 01, owned contact already existsReuse SYN-CONTACT-030. No new contact.
04 / Missing ownerHELD / R06NO_ACTIVE_OWNER, configured APAC owner is inactiveHold for an ownership decision.
05 / Conflicting territoryHELD / R05TERRITORY_CONFLICT, EU and NA signals disagreeHold until the authoritative territory is confirmed.
06 / IneligibleEXCLUDED / R01NOT_ELIGIBLE, company type is outside the target criteriaDo not route. Keep the exclusion reason.

Open downloads

Keep the routing pack.

Open the acceptance matrix, rules, fixtures and runbook below. No email address is needed.

Open the four files

Open files

Inspect the same rules and records

Use the matrix to define acceptance criteria. The rule file and the input records describe the same sample policy.

01 / Expected behaviorSynthetic reference

Acceptance matrix

Six inputs, expected terminal states, owner or exception and required destination verification.

hubspot-routing-test-matrix.csv

Open the file
02 / Policy sourceSynthetic reference

Routing rules

Ordered checks, fictional owner registry, explicit territory mapping and scope limits. Policy definitions in a readable text file.

hubspot-routing-rules.txt

Open the file
03 / Record sourceSynthetic reference

Synthetic fixtures

All six input records and independently specified expected outcomes. No customer data.

hubspot-routing-fixtures.txt

Open the file
04 / Implementation reviewSynthetic reference

Routing test runbook

What was tested locally, what needs a CRM test and how to inspect replay, ownership and exceptions before release.

hubspot-routing-runbook.txt

Open the file

Before a CRM release

Test matching, ownership and repeats in HubSpot

This lab uses explicit matches supplied in each fixture. In a build, test real matching and associations separately. HubSpot automatically deduplicates contacts by email, but companies created through the API are not automatically deduplicated by domain. Define your create-versus-update checks before writeback.

Retaining a customer owner is a deliberate policy here. HubSpot contact and company ownership are independent by default. Confirm which owner property, primary company association and synchronization settings your implementation uses.

The sample selects a named active owner and does not simulate round robin. HubSpot's Rotate record to owner action has subscription and seat requirements. Review the existing-owner override setting and available owners in the actual portal.

The lab gives the same answer every time. In HubSpot, repeats behave differently. A re-enrolled HubSpot record starts the workflow again and can repeat its actions. Test repeated submissions and destination task counts before enabling a production workflow.

Implementation references

The product details are documented

Use the reference

Connect the routing decision to the build

Project definitionSynthetic reference

Inspect the deliverables pack

Review a complementary inquiry-to-owner reference: field dictionary, acceptance fixtures, ownership and handover runbook.

Open the reference pack
Service scopeService scope

HubSpot development and RevOps

Define record matching, lifecycle, associations, routing and reporting around the way your revenue team works.

Review the service

Scope the next step

Review the rules behind your routing

Bring your ownership rules, exception records and required CRM actions. We can define the acceptance tests and scope the implementation.

Book a 30-minute call