Configuring Queues and Teams

Incident management queues and teams are configured via Git to ensure consistency, version control, and ease of deployment across environments or implementations.

Setup with incidentManagement.yaml

To add incident management config to your Portal, create a new file in the root of Workflows directory called

incidentManagement.yaml

Once this file is created in your repository, a specialized UI becomes available to guide the creation and management of queues and teams.

The UI provides 2 main areas of configuration:

• Queues - a structured list or holding area where incidents are temporarily placed until they are reviewed or assigned to the appropriate agent. They help prioritize and route work based on criteria like urgency, case type, or available resources, ensuring efficient and timely resolution.
• Teams - a named resource that will work upon one or more queues.Teams define who will work on a given queue, and the order upon which they will take incidents.

Queues

A queue has:

• A name - How it will appear when a user takes an incident from a queue
• A rank-by attribute - This is a numeric attribute (such as a transaction amount or timestamp) that define the order in which incidents are taken by operators from the queue
• A Collation function - this is applied, in aggregate to the events within an incident. It also drives queue ranking. For example, ranking an incident based upon its maximum transaction amount vs the sum of all transactions across all events in an incdent
• A rank order - defines whether the 'take' functionality pulls from the highest or lowest rank-by/collation

In addition to this there are several other optional configuration elements:

• Overflow Rule - defines the maximum size of a queue will grow to, before subsequent incidents added will take a different behavior, such as being moved to another queue, or closed automatically
• Timeout Rule - defines the maximum age of an incident before it is re-assigned to another queue (such as a higher priority queue) or automatically closed

Close Actions

Close actions specify what operators can do when resolving an incident. These are fully customizable in both behavior and order of appearance.

Common Examples:

• Mark an incident as rejected and block related identifiers.
• Enrich or update incident events with additional metadata.
• Trigger downstream investigations via third-party integrations.

Action Details
Each close action includes:

• A Name – A descriptive label for the action.
• Final Review Status – One of: accept, reject, inconclusive, or none.
• Action Steps – A series of automated tasks (such as calling a URL, or executing a model), similar to those in the Journey Editor, such as model execution or data enrichment post-closure.

You can also configure the system to hide specific close actions—particularly useful for automated processes such as system-driven closures due to overflow or timeout rules.

Teams

The Teams tab of incidentManagement.yaml is where you can:

• Create New Teams: Create Team button and assign a name eg. onboarding, operations.
• Assign Queues to Teams - can use UI here to add or remove Queues from being within scope to be worked by each team.
  

Examples:

1. The payments team may only want to investigate a Payment queue.
2. An abuse prevention team may only be interested in multi-signup focused queue.
3. An operations team without PII read permission maybe should NOT be assigned a queue looking at onboarding where this data is supplied (as they will just see hashed PII).