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.

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.

The queue is ordered by priority and 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 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.