Case Assignment Policies and Queues

What is a queue?

A queue is a named list of Cases. Cases join a queue only when a Workflow, a reviewer, or the API adds them. A queue has no filters, and each Case can be in one queue at a time.

Queues let you separate Cases for different teams. For example, a Workflow can add Cases with the tag “Fraud” or “High risk” to an escalation queue. An assignment policy that uses that queue under Cases in queues then assigns those Cases to your fraud specialists.

To create queues and add Cases to them, see Case Queues.

What is a Case assignment policy?

A Case assignment policy decides which reviewer gets which Case. It takes unassigned, unresolved Cases from the queues and Case templates that you select, puts them in priority order, and assigns each Case to a user or team with the rules that you write.

The assignment policy editor lets you:

• Route Cases with if/then rules, based on the attributes of each Case.
• Sort Cases so that the most urgent ones are assigned first, for example high-risk Cases or Cases that are nearly due.
• Balance workload with availability statuses and a maximum load for each reviewer.
• Make changes safely. You save a draft, preview the result, publish a version, and then deploy it. Every version stays in the version history.

Where to find it in the Dashboard

Go to Cases > Assignment Policies. The list shows each policy with its Name, Status, Deployed version, Source, Last updated, and Assignees. A policy is Active unless someone deactivates it. New and duplicated policies start as Active. An Inactive policy assigns no Cases, and you must activate it before you can deploy a version. By default, the list shows only Active policies. To see Inactive policies, change the Status filter.

To create, edit, publish, or deploy a policy, your role must have permission to edit Case assignment policies. To deploy a version, you need this permission in each environment that the version goes live in.

To make a new policy:

To change a policy, click its name in the list. The editor has four steps: Sources, Sort order, Routing rules, and Availability and capacity. A step that needs attention shows a Required or Issues label.

Step 1: Sources

Sources tell the policy which Cases to assign.

• Environments: The policy assigns Cases only in the environments that you select. Select All environments, All production environments, or All sandbox environments to include all environments of that type, including the ones that your organization adds later. Or select individual environments. You cannot combine an “All” option with individual environments.
• Cases in queues: Unassigned, unresolved Cases in the selected queues, across all templates.
• Cases outside queues: Unassigned, unresolved Cases from the selected templates that are not in a queue.

You must select at least one environment and at least one queue or Case template.

A queue (under Cases in queues) or a Case template (under Cases outside queues) can belong to only one assignment policy in an environment. This makes sure that two policies do not try to assign the same Case. Only an active policy with a deployed version holds its sources. Drafts, versions that are published but not deployed, and inactive policies do not. If you select a source that another active policy has deployed in one of the same environments, the editor shows an error under the source, for example “DSAR Request” is already used by deployed policy “Escalations” in Production. You can still save your draft, but you cannot publish or deploy until you remove the source from this policy or from the other policy.

Step 2: Sort order

Sort order decides which Cases the policy assigns first. The policy ranks Cases from top to bottom, in two sections:

• Custom logic: Cases that match these conditions are sorted first, ahead of the attribute sorts. Use it for Cases that you can only identify with a condition, for example Cases with a certain tag, Cases from a certain Case template, or Cases where a field has a certain value. If you add more than one custom logic rule, the order of the rules is the order of priority.
• Attributes: Sorts the other Cases by the value of an attribute, for example the date the Case was created or the SLA expiration. Select Ascending or Descending for each attribute. The second attribute breaks ties in the first, and so on.

To add a row, click Add under Custom logic or under Attributes. Drag a row to change its position in its section.

Step 3: Routing rules

Routing rules decide who gets each Case. Each rule has this shape: If a Case matches the conditions, Then assign to the selected reviewers, with a distribution method.

• The policy checks the rules from top to bottom. The first rule that matches a Case decides its assignment. The policy does not check the rules below it.
• Conditions in a group must all be true (AND). Click Or group to add a second group of conditions. A Case matches the rule if all the conditions in at least one group are true.
• Conditions can use attributes of the Case and of linked objects, for example tags, the Case template, custom fields, the linked Inquiry, or the SLA expiration date. You can use a date condition to route Cases differently when the SLA is due on a weekday or at the weekend.
• Default (all other cases) is an optional fallback for Cases that match no rule. If you do not set a default, Cases that match no rule stay unassigned.

If the policy has no rules, the step shows Assign all cases to. Every Case from the sources goes to those reviewers.

For each rule and for the default, select the reviewers in Select reviewers. You can select users, teams, or All active users. Then select a distribution method:

Click Add to add a rule above the default. Drag a rule to change its position.

Step 4: Availability and capacity

This step controls which reviewers can get new Cases, and how many.

• Assign when availability status is…: A reviewer is eligible for new Cases only when their availability status is one of the statuses that you select: Available, Busy, or Unavailable.
• Unassign when availability status is…: If a reviewer’s status changes to a status that you select here, the policy unassigns their open Cases and returns them to the pool. For example, select Unavailable so that other reviewers get the Cases of a reviewer who goes offline. A status cannot be in both lists.
• Assign until the load reaches…: The maximum number of open Cases that this policy assigns to each reviewer. The load counts Cases across all of the environments in the policy’s sources, not in each environment separately. Leave it empty for no limit. Only Cases that this policy assigned count toward the load, including Cases that the earlier policy it was copied from assigned. Cases that a person, a Workflow, or a different policy assigned do not count.
• Per-reviewer overrides: Give a specific user or team its own maximum load. Click Add under Per-reviewer overrides, select the user or team, and type the Max concurrent cases. Each user or team can have only one override. A team override applies the maximum to each member of the team. If a user has their own override, it applies instead of a team override. If a user is in more than one team with an override, the lowest maximum applies.

Save, preview, publish, and deploy

Changes go live in four stages. Until you deploy a version, the policy does not assign Cases with it.

If you cannot click Save, Preview, or Publish, hold the pointer over the button to see why. For example, Resolve all errors before publishing. means that a step shows a Required or Issues label. Open that step to see the error under the field. Save your changes before publishing. means that you must save the draft first, and No changes to save. means that the draft has no new changes.

The policy checks for Cases to assign about every 30 seconds, so new assignments can take a short time to start.

AI summary

After you save a policy, you can get a summary of it in plain English. In the AI summary panel, click Generate. If you change the policy, save your changes and click Regenerate to update the summary. Use the summary to check that the policy does what you expect before you publish it.

Version history and other actions

Click the More actions (…) menu at the top of the editor to see these actions:

• Version history: Shows every version of the policy, and where each version is deployed. Open an earlier version to see it, or to deploy it again. If you save an earlier version, it replaces the current draft.
• Undeploy version: Stops the version that you see from assigning new Cases. Other versions that are deployed in other environments stay live.
• Deactivate: Removes all deployments of the policy. The policy becomes Inactive.
• Activate: Shows instead of Deactivate when the policy is Inactive. The policy becomes Active, but Persona does not deploy a version again. To start assigning Cases, deploy a version.
• Delete: The last item in the menu. In Delete this policy?, click Delete to confirm. Persona removes the policy from every environment that it is deployed in and deletes it. Its queues and Case templates become available to other policies. You cannot undo this in the Dashboard.

When a deployment stops, Cases that the policy already assigned keep their assignee. You can deploy a version again at any time.

To copy a policy, go to the list, click the … menu on its row, and click Duplicate. In Duplicate this policy?, click Duplicate to confirm. The copy is named Copy of and the original name, and has all of the versions of the policy. Nothing in the copy is deployed, and the new draft has no sources. The original policy does not change.

Limits

• 5 custom logic rules and 5 attribute sorts in the sort order.
• 5 routing rules, plus the default. The default does not count toward the limit.
• 10 conditions in each routing rule, across all of its condition groups.

Common questions