> For the complete documentation index, see [llms.txt](https://docs.usepylon.com/pylon-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.usepylon.com/pylon-docs/support-workflows/assignment-rules.md). # Assignment Rules As your team grows, assignment rules will allow you to make sure that issues are being handled by the right person. ## Setup ### Individual Assignment Individual assignment rules can be setup using the "Set issue assignee" action in [Triggers](/pylon-docs/platform/triggers.md).
### Team Assignment First create [Teams](/pylon-docs/platform/teams.md) that model groups of people. Then, create assignment strategies to automatically assign issues to individual members of a team. When an issue is assigned to a team, the individual owner of the issue can be determined by the team's assignment policy. There are additional options to make sure you assign issues based on current [User Status](/pylon-docs/support-workflows/assignment-rules/user-status.md).
#### Round Robin Rotate between each team member equally when assigning issues. #### Recurring Set up a daily or weekly repeating schedule. Based on the time of day, issues that are assigned to a team will fall onto the appropriately individual’s plate.
#### Skill-Based Routing Skill-based routing matches issues to users who have the required skills (such as languages, product areas, or other custom fields). This ensures that issues are handled by the most qualified team members. Examples: * If a customer submits an issue in French, it is automatically routed to a team member who has the French skill configured. * Bugs related to the Payments system are routed to employees with the “Payments” skill.
#### Capacity Rules Even if a user has the right skills, they will not be assigned issues if they are inactive or have already reached their configured capacity. In those cases, routing continues to the next eligible user or falls back to other strategies.
{% hint style="info" %} The capacity calculation for round robin assignment counts issues in both `New` and `On You` status'. {% endhint %} #### Queueing When no team member is able to take on an issue assigned to the team, the issue can be left in the team queue. Issues in the team queue will automatically be assigned as team members become available. By default the queue is first in first out by issue priority. This means that `Urgent` issues are always dequeued first, followed by `High`, `Medium`, and `Low` priority issues. Each team can replace this with its own sort — see **Queue sort order** below.\ \ Issues can also be left in skill block queues which will require someone with a matching skill to be available before that issue can be assigned. 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. They apply in the order listed, so the first field decides the ordering and the ones below it break ties. 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** — 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. Each row sorts ascending or descending, and what that means depends on the field. Ascending puts the lowest number first, the oldest date first, and the SLA closest to breaching first. Descending reverses each of those. {% hint style="info" %} A **select** field sorts by the order its options are defined in on the field itself, not alphabetically. Ascending puts the *first* option at the front of the queue. Priority is a select field whose default options are defined `Urgent`, `High`, `Medium`, `Low`, which is why sorting by priority **ascending** puts `Urgent` issues first. If you have reordered or renamed the priority options, check the field's option order prior to choosing a direction. To change it, flip that row to descending, or reorder the options on the custom field. Reordering the options affects every team that sorts by that field. {% endhint %} 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.

Add

### Usage Put team assignment policies into affect by creating [Triggers](/pylon-docs/platform/triggers.md) that automatically assigns issues to a certain team.

A recipe for a common workflow

You can setup any number of workflows to make sure issues get to the right people. Some examples might be: * Routing high priority issues straight to Tier 3 support * Routing bugs about a specific topic to the subject matter expert for that product area * Reassigning issues that have had their SLA breached * Routing pre-sales issues from important accounts to your sales engineering team * Routing issues from named accounts to their CSM {% hint style="info" %} By creating subteams, you can effectively model complex assignment workflows, since each subteam can have its own assignment policy. If subteams are a part of a team assignment schedule, they will need an assignment policy set at the subteam level to work properly. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.usepylon.com/pylon-docs/support-workflows/assignment-rules.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.