Assigning an issue to a team can automatically assign the issue to a team member using several strategies. A user will be selected based on the assignment configuration if they have capacity to take on new issues.

Core Concepts

Status

Strategies can be configured to require a user be Active to be assigned. See the User Status documentation for more information. If users must be active to be assigned, then any inactive user will not be considered in any of the team assignment strategies.

Capacity

Each user on a team can be configured with a capacity for issues. By default a user has unlimited capacity. Issues that are currently assigned to a user that are NOT On Hold or Closed count towards capacity.

Capacity is configured at the user and team level. This means that a user that is on both Team A and Team B can be configured with a different capacity on each team.

A capacity of 0 is allowed and means the user cannot take on any issues.

If a user has reached their capacity they will not be considered in any of the team assignment strategies.

Secondary Team

When no user on the team can be assigned (because of capacity rules or because of status rules) the assignment will fall back to the chosen secondary team. Team assignment then runs on the secondary team recursively (and falls back to that team's secondary if needed).

Note that cycles are not allowed. You cannot configure the following secondary chain:

Team A -> Team B -> Team A

Round Robin

We implement a least recently assigned round robin strategy. This means that when one assignee must be chosen from multiple entities (users or subteams) we select the entity that has been assigned (by round robin) least recently. If a user or subteam was assigned by schedule (they were the only option) or manually, their position in the round robin will not be affected. If a tie still occurs we will assign alphabetically.

Skills

Skills are attributes that can be assigned to users that carry over to all teams they are a part of. They are generally issue fields that can be used to filter issues (such as custom fields) or language.

The language skill can be set on the team page as well as on a user's profile.

Strategies

Manual

No assignment is automatically made and instead the issue assignee must be set via triggers or in the kanban manually.

Schedule

A user or subteam can be selected for certain blocks during the day.

When a user is selected for a block, all issues assigned during that block will be routed to them while they are allowed to be assigned. If they cannot be assigned (for example they have no capacity remaining) then assignment will fall back to the secondary team.

Example: Weekend-only assignment To route tickets to a specific person only on weekends, navigate to Settings > Teams > [your team] > Assignment, and set the assignment method to “Recurring”. Configure the Saturday and Sunday blocks to only include your weekend person — tickets that arrive during those days will route exclusively to them. Note that recurring assignment still respects capacity limits, so set the weekend person’s capacity high or to unlimited to ensure tickets don’t spill over to other agents during the weekend.

When a subteam is selected for a block, all issues assigned during that block will be routed to the subteam, where its team assignment strategies will run to determine the assignee. The subteam that determines the final user to be assigned will be the team assigned to the issue.

Note that when blocks overlap, during the overlapping period we will round robin between the users and subteams present in blocks that cover the overlapping period.

Issue Routing

Issue routing employs a waterfall hierarchy of strategies built upon skills.

Each strategy can employ mulitple skillsets of equal weight. The user(s) that best match the strategy for the issue being assigned will move on to the next strategy. "Best match" in this case means the user(s) that have the most number of skills that match the issue.

If no users match the skills required for the issue then all users move on to the next strategy. If there is only one user left, that user will be assigned to the issue. When there are multiple users left after applying each successive strategy the final strategy used is round robin.

Queueing

Each skill block has an option of leaving an issue in the queue if there is no one who is able to take on the issue. If there is a tie and multiple users meet the skill requirements for an issue then the routing will proceed to the next block.

By default, the queue is ordered by priority and then time of entry. This means issues that have been waiting get priority but can be preempted by higher priority issues that come into the queue later. The default order of priority is Urgent, High, Medium, then Low.

Issues wait in the queue indefinitely until someone is available to take on the issue. Availability is defined by capacity requirements as well as whether a user is marked as Active. The Active requirement is a setting on the team that can be toggled.

This also applies when you reassign an issue that already has an assignee to a team with Overwrite existing assignee enabled: if no team member is currently available (for example, all members are at capacity), the previous assignee is cleared and the issue joins the queue, then is assigned automatically once a member becomes available.

Queue sort order

Each team can replace the default priority ordering with its own sort. Go to Settings > Teams > [your team] > Assignment. The Queue sort order section appears once the team is configured to leave issues in the queue.

Choose up to four fields to sort by. They apply in the order listed, so the first field decides the ordering and the ones below it break ties. Each field sorts ascending or descending, and rows can be dragged to reorder them. Time entered queue is always the final tiebreaker and cannot be changed or removed.

You can sort by:

• Issue fields — number, date, and select custom fields on the issue.

• Account fields — the same field types, read from the issue's account.

• SLAs — Issue Response SLA, Issue Resolution SLA, Team Response SLA, Team Resolution SLA, or Next upcoming SLA. These sort by when the SLA is due to breach, so the most urgent issue comes first.

What ascending and descending mean

The direction you choose is interpreted differently depending on the field type. Sorted ascending, a number field puts the lowest value first, a date field puts the oldest date first, and an SLA puts the issue closest to breaching first. Descending reverses each of those.

A select field is sorted by the order its options are defined in on the field itself, so ascending puts the first option at the front of the queue.

Priority is a select field. By default its options are ordered Urgent, High, Medium, Low, so sorting by priority ascending drains Urgent issues first — usually what you want, even though the word suggests otherwise. If your workspace has reordered or renamed the priority options, check the option order before choosing a direction.

If a select field drains in the wrong order, you have two ways to fix it: flip that row to descending, or reorder the options on the custom field itself. Reordering the options affects every team that sorts by that field, so prefer flipping the direction if you only mean to change one team.

Issues with no value for a sort field are always placed last, whichever direction the field is sorted in. A team with no queue sort configured keeps the default priority ordering described above.