Staging draft Work in progress · For review; coverage and acceptance incomplete

Manage SLA policies¶

Use this guide to prepare timing targets, inspect policy usage and plan changes. The steps describe the intended 06 Final Screens journey. The frontend currently presents previews; a navigation change, example status or success-looking page is not evidence that the backend saved your policy.

Before you begin¶

You need permission to view workflow definitions to read policy lists/details, and permission to manage workflow definitions to create, update or deactivate a policy. The ability to open an editor does not grant that permission. Confirm your organization's timezone, business hours and holidays, the affected workflow steps, and who should receive or take over overdue work.

Choose a recognizable policy name and unique key. Description is optional in the backend. Agree positive response and completion targets, a valid warning lead, and any escalation stages. Read what the targets mean before entering minute values.

Find a policy¶

Open Operations, then the Workflow definitions area and SLA policies.
Choose the page size and status filter, then Apply filters. Use Previous and Next to browse other pages.
Choose Open policy on the relevant row. Check the selected policy name, key and status.
Review Overview, Usage and Escalation rules before deciding whether to change the policy.

The backend defaults to active policies when no status is supplied. The designed library also offers all statuses and inactive policies. If no policy matches, use Show all policies or broaden the status filter. A successful empty result differs from a failed or restricted read; complete loading, error and permission companions still need verification.

The list shows timing targets and counts, but policy detail is needed for the full escalation rules and usage. Sample policy names and figures are examples, not your organization's saved data.

Create a policy¶

The intended flow has three sections:

Choose Create policy. In Policy details, enter the policy name, key and optional description, then Next step.
In Timing rules, enter response target, completion target and warning lead in minutes. Response must not exceed completion; warning lead must be between zero and completion. Continue to the next section.
In Escalation rules, review every rule's delay, action and destination. An alert can have no explicit destination. A reassignment must identify exactly one person, position or pooled queue. Reason text is optional for each rule.
Once all sections are complete, use Create policy and verify the saved detail before assigning the policy to workflow steps.

The screen family still has input gaps. The second escalation rule lacks its own visible delay input, and a “no target” statement appears beneath reassignment. The reason field is shown once even though the contract supports a reason per rule. Do not interpret those examples as permission to omit a reassignment target or silently apply one reason to every stage. Connected creation, added rules, complete validation and recovery must be finished before this is a reliable production procedure.

The sidebar shows a create action on earlier sections too. Its presence does not mean the remaining inputs are optional or that incomplete settings can be saved.

Edit an existing policy¶

Open the policy and review Usage, including saved definition references and active-task count.
Choose Edit policy. Review policy details, then timing rules and escalation rules.
Retain all rules you intend to keep. Updating replaces the rule set; omitting a rule removes it from the policy.
Use Save changes, reopen the policy and check its saved key, targets and full rule set.

The key is normalized to uppercase and must remain unique within the organization. Existing task snapshots are not recalculated by this update. Coordinate changes with the owners of definitions and upcoming work; do not promise that a shorter policy target immediately changes every open task.

The inspected preview moves between sections using navigation. It has not established saved multi-step form state, a reliable unsaved-change warning or concurrent-edit recovery. Keep the intended changes available until a connected saved result is verified.

Deactivate a policy¶

Review the policy's references and arrange replacement timing for future work first. Deactivation is allowed by the inspected handler without checking whether usage counts are zero.

The detail design offers Deactivate policy. Its companion represents an already-inactive result and offers Back to detail and Back to library. A complete confirmation and failed-save sequence has not been established by the inspected family, so do not treat opening that companion as proof that deactivation occurred.

After a verified change, the record remains readable in inactive/all-status views. Definitions still retain their references, and existing tasks keep their timing snapshots. The flow does not capture a deactivation reason. There is no verified reactivation or deletion journey here.

Check escalation choices¶

Resolve the business responsibility before selecting a destination. A person must be eligible when the rule runs. A position may resolve through its occupants or fallback position. A pooled queue depends on its current eligible membership. For approval work, the final reassignment must identify a person.

The authoring choices are populated from staff and live organization-structure reads. Some failed reads can appear as empty choices; an empty selector does not prove that no staff, position or queue exists. Ask an administrator or support to investigate missing choices rather than substituting an unrelated destination.

An alert's reason text does not select its recipient, and mentioning a supervisor in that text does not route the alert to that supervisor. Escalation delays start from the completion deadline. The example that mentions a missed response target needs correction before it is used as an explanation of those stages.

Handle failures and uncertain results¶

Situation	Response
Duplicate key	Check whether the policy already exists. Choose a distinct key for genuinely new work rather than creating duplicate copies after an uncertain save.
Invalid timing	Check all three values together, including zero/negative values and response or warning exceeding completion.
Reassignment rejected	Confirm exactly one target is configured and can resolve appropriately for the task type.
Expected choices are absent	Investigate configuration and lookup failure; do not equate an empty option list with an empty organization.
Connection fails during a change	Reopen the policy and compare saved values before repeating the mutation.
Existing tasks show old targets	Check their saved timing snapshots and creation time. A policy edit does not retime those tasks.
New work has no deadline after deactivation	Check the definition's policy reference and arrange a usable active replacement.
A due alert or reassignment has not appeared	Keep the task reference and due time. Ask support to check processing, target resolution and delivery; a scheduled deadline alone does not prove delivery.

Provide the policy name/key, task or workflow reference when relevant, approximate time, intended change and visible message. Share sensitive request contents only through an authorized support channel when necessary.

For first-response rules, authority pauses, catch-up processing and missing emails, read deadline monitoring and alert delivery. The policy's due time and a provider's delivery result describe different stages.