Worked Example

This chapter uses sample policy data to show how queue resolution selects a queue, creates a work item, calculates SLA dates, and closes the work item when the policy is submitted again.

The example values are illustrative. They show the expected decision flow and are not required configuration values.

Queue Resolution

This example follows policy POL-1001 after it is submitted and pended.

Policy Data

The submitted policy has two pend reasons and policy-specific dimensions that can be used for queue matching.

Table 1. Policy Input Data
Policy Code	Brand	Pend Reasons	Messages	Line of Business	Group Account	Policy Type	Policy Broker
POL-1001	UCH	PEND001, PEND002	M1, M2	Individual	GA-100	Standard	BRK-01

Queue Configuration

The following queue configuration is available when queue resolution starts. The example uses a subset of the policy dimensions for readability. Queue definitions can also use other policy-specific dimensions, such as group client, policy broker, and policy agent.

Table 2. Candidate Queue Configuration
Queue	Queue Pend Reason	Message Group	Priority	Brand	Line of Business	Group Account	Policy Type	Condition Dynamic Logic
Q1 Eligibility Review	PEND001	MG1	1	UCH	Individual	GA-100	Standard	DL-Q1
Q2 Policy Operations	PEND001	MG2	1	UCH	Individual	NULL	Standard	DL-Q2
Q3 Broker Review	PEND001	MG1	2	TOP	Individual	GA-100	Standard	DL-Q3
Q4 General Policy Review	NULL	NULL	3	UCH	NULL	NULL	NULL	DL-Q4

The message groups used by the queues contain the following messages.

Table 3. Message Group Configuration
Message Group	Messages
MG1	M1, M2
MG2	M1, M2, M3

The pend reasons are configured with the following priorities.

Table 4. Pend Reason Priority
Pend Reason	Priority
PEND001	1
PEND002	NULL

Step 1: Identify the Primary Pend Reason

The system sorts the policy pend reasons by priority and then by pend reason code.

Table 5. Primary Pend Reason Selection
Order	Pend Reason	Reason
1	PEND001	It has priority `1`.
2	PEND002	It has no configured priority, so it ranks after `PEND001`.

The primary pend reason for policy POL-1001 is PEND001.

Step 2: Identify Eligible Queues

Each queue is checked against the primary pend reason, policy messages, and policy-specific dimensions.

Table 6. Queue Eligibility Result
Queue	Result	Reason
Q1 Eligibility Review	Eligible	The queue contains `PEND001`; messages `M1` and `M2` are in `MG1`; and the configured brand, line of business, group account, and policy type match the policy.
Q2 Policy Operations	Eligible	The queue contains `PEND001`; messages `M1` and `M2` are in `MG2`; and the queue matches the policy dimensions. The blank group account acts as a wildcard.
Q3 Broker Review	Not eligible	The configured brand is `TOP`, but the policy brand is `UCH`.
Q4 General Policy Review	Eligible	No pend reason or message group is configured, and the blank dimensions act as wildcards.

Step 3: Order Eligible Queues

The eligible queues are ordered by whether they contain the primary pend reason, then by queue priority, and then by queue code.

Table 7. Ordered Eligible Queues
Order	Queue	Queue Priority	Reason
1	Q1 Eligibility Review	1	Contains the primary pend reason and has the highest queue priority.
2	Q2 Policy Operations	1	Contains the primary pend reason and has the same priority as `Q1`; queue code ordering places it after `Q1`.
3	Q4 General Policy Review	3	Does not contain a specific pend reason and has lower queue priority.

Step 4: Execute Condition Dynamic Logic

The system evaluates the condition dynamic logic in the ordered sequence. The first queue that evaluates to true becomes the winning queue.

Table 8. Condition Dynamic Logic Result
Queue	Result	Outcome
Q1 Eligibility Review	True	`Q1 Eligibility Review` is selected as the winning queue.
Q2 Policy Operations	Not evaluated	Evaluation stops after `Q1` is selected.
Q4 General Policy Review	Not evaluated	Evaluation stops after `Q1` is selected.

The system creates a work item for policy POL-1001 in Q1 Eligibility Review.

Work Item Creation and Closure

This example shows how the policy work item is created and closed through policy submit processing.

Table 9. Policy Work Item Creation and Closure
Step	Event	System Behavior	Result
1	Policy `POL-1001` is submitted and pended.	Queue resolution runs and selects `Q1 Eligibility Review`.	Work item `WI-POL-1001` is created with status `Open`.
2	A queue user reviews the policy work item.	The user completes the required policy review or correction outside the work item record.	The policy is ready to be submitted again.
3	Policy `POL-1001` is submitted again.	The system checks for an open work item on the policy. If the work item is not in `Done` status, the system closes it and records the status history.	Work item `WI-POL-1001` is closed.
4	Policy `POL-1001` still has pend reasons after the new submit.	Queue resolution runs again for the remaining pends.	A new work item is created for the winning queue.

If the open work item is on hold when the policy is submitted, the system releases the hold and updates the hold history before closing the work item.

Default SLA Calculation

This example shows the difference between the work item SLA and the global SLA for a policy work item.

Table 10. SLA Configuration
SLA Type	Due Time	Risk Time
Work item SLA	2 days after work item creation	1 day after work item creation
Global SLA	5 days after the latest policy version creation date	4 days after the latest policy version creation date

The policy version is created on 2026-06-01 08:00, and the work item is created on 2026-06-01 10:00.

Table 11. SLA Calculation Result
SLA Type	Risk Date and Time	Due Date and Time
Work item SLA	2026-06-02 10:00	2026-06-03 10:00
Global SLA	2026-06-05 08:00	2026-06-06 08:00

The work item SLA is based on when the work item is created. The global SLA is based on the latest policy version creation date.