SLA policies, deadlines and escalation¶

An SLA policy sets timing expectations for a workflow task: when someone should first respond, when the work should finish, when to warn them, and what should happen if the completion deadline is reached. Here, SLA means a configured service-level target. Creating a policy does not establish a contractual guarantee or prove that notifications have been delivered.

Availability: The backend implements policy creation, updating, deactivation, task timing and scheduled escalation processing. The intended administration journey follows twelve Final Screens. The inspected frontend uses sample data and preview navigation; connected saving and environment delivery remain unverified. This draft explains administration, timing, monitoring, SLA email dispatch and governed policy changes. Governed actor attribution, complete channel integration and hosted behavior still need verification.

Read Manage SLA policies for the intended steps, preparation and recovery.

Read deadline monitoring and alert delivery to distinguish first response, completion, paused work, processing and provider-reported delivery.

Read governed policy changes, activity and retained data for proposal review, changed-policy checks, outcome uncertainty and export/deletion limits.

What the policy controls¶

Response and completion targets must be positive. Response cannot exceed completion. Warning lead must be zero or positive and cannot exceed completion. A policy can have no escalation rules; the deadline settings still have meaning.

The calendar uses the organization's headquarters timezone, configured working days and hours, recognized breaks, and holidays. For example, with Monday–Friday hours of 09:00–17:00, a 12:00–13:00 break, no holidays and a UTC timezone, a 90-business-minute target starting Tuesday at 11:30 falls due at 14:00. That example depends on the stated calendar; it is not a universal working-day definition.

A valid headquarters timezone and at least one usable workday are required when calculating these targets. Missing calendar setup is an operational issue to resolve, not an instruction to assume round-the-clock work. “One business day” also needs a defined number of business minutes; different organizational schedules need not have equal-length days.

Policies and tasks have different lifecycles¶

A newly created policy is active. An administrator can update its name, key, description, targets and escalation rules, or deactivate it. Updating replaces the supplied escalation-rule set, so omitted rules are removed from the policy.

When an eligible task is created with a selected active policy, the system saves that task's policy identity, timing targets, deadlines, calendar and escalation schedule. Editing the policy does not recalculate those existing saved task timings. Later tasks can receive different snapshots. A change during an ongoing workflow can therefore affect a later task without rewriting its earlier tasks.

Deactivation removes the policy from active authoring choices and prevents a new timing snapshot from being built from that inactive policy. It does not delete the policy, remove references from definitions, cancel tasks or erase their existing timing. Review dependent definitions and arrange a replacement before deactivating a policy that should continue protecting new work. An inactive reference can result in a new task without a policy timing snapshot.

The inspected administration surface has no reactivation or deletion action. Editing an inactive policy does not reactivate it. Do not infer those actions from an editable record or a domain method used elsewhere.

Understand usage before making a change¶

The detail view supplies three different measures:

• Published workflow definitions with at least one step that references this policy.
• Draft workflow definitions with at least one such step.
• Tasks that retain this policy identity and are not completed, cancelled, skipped or returned.

The first two count distinct saved definitions, rather than every referencing step. The task count is based on each task's saved policy identity. It is not calculated by counting all tasks in workflows whose current definitions mention the policy. None of these figures proves successful delivery, compliance, employee performance or adoption across the whole organization.

In the library, the total matches the selected status filter. Active/inactive totals and escalation-rule totals shown for the current page have a different scope. Keep that distinction when comparing pages or presenting figures to business leaders.

Escalation and responsibility¶

An alert calls attention to work. Reassignment changes the responsible person, position or pooled queue. Reassignment requires exactly one configured target. The target must also resolve when the rule runs; a saved name alone is insufficient.

The current processor considers the requester and current assignee or queue members, then any configured rule destination. A target-free alert does not automatically identify an operations supervisor. Approval-task reassignment must resolve to an individual; a queue-only destination cannot satisfy that requirement. Escalation does not itself approve or complete the work.

Rules are scheduled by their delay from the completion deadline, with the sequence number breaking ties. Make the numbering and delays agree with the intended order. Processing is periodic, and one sweep can catch up on several overdue stages. A due time is not a promise of notification arrival at that exact instant. Failed target resolution can postpone a stage.

Responsibilities and rollout¶

Process owners agree realistic response/completion targets, recipients and exception handling. Administrators maintain the calendar, assignments and policy configuration. Managers review unresolved work and distinguish a delay from its cause. End users should follow the task's actual deadline and responsibility, and report missing or inconsistent information.

Platform and support teams investigate failed lookups, stalled sweeps and delivery problems through their authorized operational channels. Business leaders should require a representative end-to-end test before relying on timing reports or escalation as a control. This feature does not establish pricing, financial penalties or a contractual service commitment.

The public workflow execution explanation describes route and completion limits. The workflow authoring guide explains the surrounding definition lifecycle.