Troubleshooting: My Record Wasn't Routed

1. Did the workflow action actually run?

Open the record's workflow history in HubSpot and confirm the Distributely action was reached.

There is an important subtlety. The action reports success in HubSpot as soon as the request is accepted, not when the owner is written. A green step in HubSpot does not prove an owner was assigned. Treat it as "the request arrived" and nothing more.

Confirm the outcome in Distributely's Analytics. Run Recent Distributions for the record's date and object type and look for its HS Object ID. If it is not in that table, the request never reached Distributely, and the problem is on the HubSpot side, usually enrollment.

2. Is the mode right?

A team only participates in a run whose mode matches its own settings. Check the Mock and Live checkboxes under Team Information. A team with only Mock enabled will never receive Live traffic.

Also check the mode on the workflow action. Mock never writes to the record. It picks an owner and records the result for review, but leaves the record alone. A Mock run that looks perfect in analytics has, by design, changed nothing.

3. Is the team eligible?

On the team, confirm three things:

• Team Active is checked. Inactive teams are not loaded at all.
• The team's Object Type matches the record. A team set to Deal never sees a Contact.
• The team has at least one rule, and every rule has at least one condition.

That last point matters more than it looks. A rule saved with no conditions is invalid, and it does not merely get skipped: it stops the whole team from matching anything. Delete any empty rule or give it a condition.

4. Did any rule match?

Open Team Rules and compare each condition against the record's actual property values. Check the Match Type too: Match ALL Conditions requires every condition to be true, Match ANY Condition needs only one.

The most common cause by far is a property that is empty when the workflow runs. A condition on Country, Lifecycle Stage, or a custom field will not match a record where that field is still blank, even if it fills in five minutes later. If another workflow, integration, or form sets the property, make sure it lands first. A short delay ahead of the action often fixes this outright.

5. Is there a Default Team?

If no team's rules match, Distributely routes to the team with Is Default Team checked on the same object type and mode. Without one, records that match nothing go nowhere. 

6. Does the team have active members?

Open the team's members list. A team with no active members is skipped. 

7. Are any members available?

This is the most common cause of a matched team producing no owner.

A member with no schedule configured is never available. There is no implicit "always on" default. A team set up without schedules will match records and then fail to assign every time.

Then check, in this order:

• Time off. A member inside a time-off period is unavailable all day.
• Working hours. Availability is checked against the member's hours for the current day of the week.
• Timezone. Hours are read in the member's own timezone, not yours. A wrong timezone makes someone look unavailable during their actual workday.
• Caps. A member who has hit a cap is unavailable until that cap's period resets.

If the team's Availability Source is HubSpot user schedules, the hours and out-of-office data come from HubSpot, so check them there.

8. Is Fallback Behavior set?

When a team matches but cannot produce an owner, its Fallback Behavior decides what happens:

• Skip to next team moves on to the next matching team.
• Fallback owner assigns the Fallback Owner picked on that team.
• Standard round robin retries with plain round robin across available members.
• Ignore availability (round robin) assigns anyway, ignoring schedules, time off, and caps.

If every team is set to Skip to next team and none can assign, nothing happens. One safety net remains: the Default Fallback Owner under Portal Settings. If that is empty, the record ends with no owner and a failure reason in analytics.

9. Is the Owner Property a real HubSpot owner property?

The team's Owner Property decides which field gets written. The default is the standard HubSpot owner field.

If you pointed it at a custom property, that property must be an owner-type property on the same object. A text or dropdown field makes the write fail while everything upstream still looks successful. Check this whenever analytics says a record succeeded but the record has no owner.

Still stuck?

Use the Distribution Explanation Agent for a per-record answer in plain language. It names the teams considered, the rules matched, the members ruled out and why, and the final outcome.

The action is green in HubSpot. Doesn't that mean it worked?

No. It means the request was accepted. Confirm in Distribution Analytics or on the record.

Everything looks configured and it still fails at the member step.

Check schedules first. A member with no schedule saved is never available, and this is by far the most common cause.

Can I make a catch-all so nothing is missed?

Yes. Set one team per object type as Is Default Team, and a Default Fallback Owner under Portal Settings as a last resort.