Skip to content
Docs
opendesk.shOpen app

Routing

How a new ticket finds its team, how to write routing rules and test them, and how customers see which address they wrote to.

Routing decides which team a new ticket goes to. Most of it needs no setup: email goes to its address’s team, and a chat goes to its widget’s team or the topic the visitor picked. Routing rules go further and send tickets by what they say or who sent them, say every invoice question to Billing whatever address it came in on.

  1. How a new ticket gets its team: the address or widget first, then the rules, then the team’s assignment.
  2. Drag handles: rules are checked from the top, so drag to change the order.
  3. A rule: its name, a summary of its conditions, how many tickets it has routed, and its team. Click it to edit.
  4. On or off: a rule that is off is skipped.
  5. Test routing: try a sample email or chat and see where it would go.
  6. New rule: add a rule.

A new ticket gets its team in this order:

  1. Where it arrived. An email gets the team of the address it was sent to. A chat gets the team of the topic the visitor picked, else the widget’s team. A ticket created through the API gets the team it names.
  2. Routing rules, from the top. The first rule that is on and matches moves the ticket to its team, whatever step 1 chose. The rules after it are not checked.
  3. Triage, when the ticket still has no team and triage sorts tickets into teams. See Triage and assignment.
  4. Automations run next and can still move the ticket to a team. See Automations.

Then the team’s assignment method picks a person. A reply on an existing ticket joins that ticket wherever it was sent, and is never routed again.

  1. Open Settings, then Routing

  2. Click New rule, or a rule to edit it

    Give the rule a name and leave it On. Choose whether Any matches or All match, then add up to 20 conditions.

    1. Name and On: a rule that is off is skipped until you turn it on.
    2. Any matches or All match: whether one condition is enough, or every one must hold.
    3. Conditions: a field, a test such as contains or is, and a value. Text is compared without regard to case.
    4. Add a condition: up to 20 in a rule.
    5. Send to team: where matching tickets go. The team’s assignment method then picks a person.
  3. Pick what to check

    Click a condition’s field to choose what it checks, grouped by where the ticket arrived, who sent it and what it says.

    Field Checks
    Address received at The exact address the customer wrote to, an alias included.
    Mailbox, Brand, Chat widget Where the ticket came in. Brand shows once you have a second brand.
    Channel Email, chat, API or portal.
    Page URL, Topic For chats: the page the visitor started on, and the topic they picked.
    From email, From domain The sender, such as everyone at northwind.io.
    Contact fields Your custom fields on the contact.
    Subject, Message What the ticket says.
    Ollie decides A question for Ollie. See the note below.
  4. Save, and put it in order

    Save the rule. Back on the routing page, drag it above or below the others: the first match wins, so put specific rules above general ones.

The Test routing panel on the routing page shows where a message would go, without creating a ticket or counting a run on any rule.

  1. Write a sample email

    Choose Email, pick the address it is Sent to, and fill in From, Subject and Message. Click Test.

    Steps shows what was checked in order: the address’s team, then each rule, matched or not. Rules below the one that matched are not checked. The result gives the team, brand, the address replies go from, the assignment method, and what decided it.

  2. Or a sample chat

    Choose Chat, then the Widget, the Topic the visitor would pick, the Page they start on and their First message.

Every ticket shows its team, brand and reply address in its details, and how it was routed under Details.

  1. Received at: the exact address the customer wrote to. When it was an alias, hover it to see which address it belongs to. Chats show the page they Started on instead.
  2. How it was routed: such as Arrived at an address, From the widget and topic, Routed to a team by rule, Sorted into a team by Ollie, or Moved by a teammate.

Customers see the address they wrote to. Each message in the timeline shows which address it was sent to.

  1. Replies go out from the ticket's address

    A new email ticket replies from the address it arrived at. When the customer wrote to an alias, replies go out as the alias where the mailbox allows it: SMTP mailboxes send from the alias, and Google, Microsoft and opendesk’s own sending use the mailbox’s address with the alias as the reply-to address. A chat or API ticket replies from the brand’s address for the ticket’s team, else the brand’s default reply address.

  2. Change it for a reply

    Above the reply box, Replying as shows the name and address the customer will see. Click it to pick another address of the ticket’s brand. This reply and the next ones go from the address you pick. Addresses of a private team are only for its members.

  3. Moving to another team can switch it

    When you move a ticket to another team, and its address belonged to the old team, replies switch to the new team’s address of the same brand. The move dialog tells you before you confirm, and the reply box notes the switch. The customer’s thread stays together. See Move a ticket to another team.

What customers see on every email, replies, auto-replies and satisfaction surveys alike:

  • From name: each address’s sender name format, set in Mailboxes. It can use {agent}, {agent_first}, {team}, {brand} and {mailbox}, such as {agent_first} from {team}. On emails without a person, such as auto-replies, the agent part is left out.
  • Signature: the team’s signature when it has one, else the address’s. See Signature.
  • Satisfaction surveys ask “How did Billing do?” with the ticket’s team, or the brand when it has none.
  • In chat, the widget header shows the team’s name once the conversation has one, and its hours when it is closed.

A workspace can have up to 200 routing rules, each with 1 to 20 conditions and at most 3 Ollie decides conditions. Deleting a team can move its rules to another team. See Delete a team.

Edit this page on GitHub