How a Record Gets Routed

The short version

Distributely picks a team first, then picks an owner inside that team, then writes that owner onto the record. When a step cannot produce an answer, a fallback takes over and routing continues.

Step 1: The record enters the workflow

A contact, company, deal, ticket, lead or custom object enrolls in a HubSpot workflow. The workflow calls the Distributely action, and the action passes along the settings you chose on it: Team Selection Logic, Owner Selection Logic, Distribution Mode, and (for attribute routing) Attribute for owner selection.

Step 2: Eligible teams are gathered

Distributely collects every team in your portal that clears three checks:

• Team Active is on.
• The team's Object Type matches the record's object type. A deal only ever considers deal teams.
• The mode flag (Mock vs Live) on the workflow action matches the mode flag on the team in Distributely.

Step 3: Team rules are evaluated. Every team whose rules match stays eligible.

Step 4: Eligible teams are tried in Team Order

The eligible teams are sorted by Team Order, lowest number first, and tried one at a time. The first team that produces an owner wins. Order your teams from most specific to most general. 

Step 5: If no team's rules match, the Default Team is used

If nothing matched in step 3, Distributely looks for an active team of the right object type with Is Default Team checked, and uses it. The Default Team's own rules are not consulted at this point — being the default is enough.

If there is no Default Team, routing goes straight to step 9.

Step 6: Member availability is evaluated

Inside the chosen team, each member is checked. A member is available only when all of these hold:

• The member is marked active on the team.
• The member is inside their working hours, per the team's Availability Source.
• The member is not on time off.
• The member has not reached a configured cap.

Anyone failing a check is excluded for this assignment. 

Step 7: The owner selection method picks a member

Whatever you chose in Owner Selection Logic on the workflow action now runs across the available members: Round Robin, Weighted Round Robin, Attribute-based Round Robin (Team). This field on the action is what decides the algorithm.

Step 8: If the team cannot produce an owner, its Fallback Behavior fires

A team can come up empty — nobody available, or nobody matching the attribute. That team's Fallback Behavior decides what happens:

• Skip to next team
• Fallback owner
• Standard round robin
• Ignore availability (round robin)

If the fallback does not produce an owner either, the next eligible team in Team Order is tried. See Team fallback behavior.

Step 9: The portal fallback owner catches what is left

If no team produced an owner, Distributely assigns the portal-level fallback owner, if one is configured. This is the last safety net. Without it, the record is left unassigned and the run is recorded as a failure. See The portal fallback owner.

Step 10: The owner is written to the record

The selected owner is written to the record's owner property. By default that is the standard HubSpot owner field; a team can point at a different one using its Owner Property setting.

In Mock mode, nothing is written to HubSpot. Distributely still runs the full decision and records the result so you can review it.

FAQ

If two teams match, does the record go to both?

No. Both stay eligible, but the record gets one owner. The teams are attempted in Team Order and the first one that produces an owner ends the process.

Does the Default Team have to have rules that match?

No. The Default Team is used precisely because nothing matched. Its rules are skipped in that case. It still needs Team Active, the right Object Type, and the right mode checkbox.

Why did a record go to a team whose rules clearly do not fit?

Usually because a higher-priority team matched but could not staff the assignment, and its Fallback Behavior was not Skip to next team. Check the fallback settings on the teams above it in Team Order.