Team Weighting

Summary

When the distribution engine decides which team should receive a record, it evaluates teams one at a time, in a fixed priority order, and assigns to the first team that both qualifies and has someone available. This article explains how that order is set, how ties are broken, and what happens when a team can't accept the assignment.

Setting team order

Each team has a Team Order field (found on the team's detail screen). This is a plain number:

• Lower numbers are evaluated first. A team set to 1 is checked before a team set to 5.
• Teams are otherwise evaluated in the same order every time — this is not round-robin or randomized at the team level. (Round-robin and weighted logic exist, but they only apply to picking a person inside whichever team is chosen — not to picking the team itself.)
• New teams default to 0 unless you set a different value, which means an unconfigured new team will be evaluated before any team you've explicitly numbered 1 or higher. Set Team Order deliberately on every new team rather than relying on the default.
• Duplicate numbers are allowed — the system does not warn you if two teams share the same order value.

Ties

If two teams have the same Team Order value, the tie is broken by which team was created first (an internal, non-visible detail — it does not correspond to alphabetical name or anything shown on screen). Do not rely on tie-breaking behavior — if two teams need a guaranteed relative order, give them distinct Team Order values.

What "evaluated first" actually does

For each portal, the engine builds its candidate list of active, live teams sorted by Team Order, then walks that list top to bottom:

1. If routing rules are configured, a team is skipped if it doesn't match — but this only filters the list, it doesn't change the order.
2. For the first team that matches, the engine checks whether it has an available member to assign to.
3. If yes, the assignment is made there and the engine stops — teams further down the list are never evaluated for this record.
4. If the team has no available member, its Fallback Behavior setting determines what happens next (see below), and if nothing can be assigned within that team, the engine moves to the next team in order.

When a team can't take the assignment

Each team has its own Fallback Behavior setting that controls what happens when no member is normally available:

• The team can be configured to force an assignment anyway (ignoring schedule or availability rules), assign to a designated fallback owner, or simply be skipped so the engine moves to the next team in order.
• If a team has a fallback owner configured, that team can still receive the assignment even with zero available members.

If no team qualifies at all

• If no team in the ordered list matches the routing rules, the assignment falls back to whichever single team is marked as that portal's default team.
• If nothing produces an assignment anywhere, the system falls back to the portal-level Fallback Owner, if one is configured. If that's also unset, the assignment fails.

Things to know / current limitations

• The visual order of teams on the team list screen is not the evaluation order. The list is not sorted by Team Order. To know a team's actual priority, open that team's detail screen and check its Team Order field directly.
• Inactive teams are never evaluated. A team must be marked active to be considered at all, regardless of its Team Order value.