Understand deadline monitoring and alert delivery¶
A deadline, an overdue notice and a delivered email are different facts. The deadline comes from the task's saved policy and business calendar. Background processing checks that deadline and requests notifications. A separate delivery path sends email and records what the provider reports. An overdue task can exist before its notification arrives.
Availability: This explanation follows the inspected backend. The administration screens remain previews, and a connected environment, notification channels and recipient delivery have not been accepted. This page explains behavior and support decisions; it does not introduce a new monitoring screen or a manual pause control.
Response and completion are separate¶
The response target measures the first recorded response. Claiming a pooled task records that first response if none exists. Acknowledging an eligible ordinary assigned task also records it without completing the work. Completing a task records a response if no earlier response exists; returning an eligible task for correction also records a first response when needed. Simply opening a page is not one of these recorded actions.
Use the work-queue guide for claiming and acknowledgment, and the request guide for request decisions and correction. Acknowledgment is not an approval decision and is not an action for approval tasks.
The completion target asks when the task finished. A response on time does not imply completion on time. For tasks using the newer timing model, processing can still report a missed response or completion target after the task finishes if the recorded action was late. Completing late does not erase that fact. A task completed on time does not acquire a late-completion notice merely because the background check runs later.
What background processing does¶
The configured schedule requests a check every minute. Processing selects eligible tasks with due warnings, missed targets or escalation stages. It works through bounded batches and continues when more work remains. Timing is therefore a target for processing, not a guarantee of an alert every minute or email arrival at an exact second.
Warnings become eligible at their warning time. A response or completion breach requires the deadline to have passed. A zero-delay escalation can become eligible at the completion deadline itself. If processing first sees a task after its completion deadline, it can send the overdue notice without first sending a separate warning.
The newer model groups the response, completion and escalation milestones reached during one task-processing pass into email requests for the affected recipients. A warning alone does not create an SLA email through this path. Several overdue stages can be processed together, so one message can describe several milestones. In-app or collaboration notification requests are separate from these emails.
Cancelled, skipped and returned tasks are excluded from the due-work scan. Suspended, cancelled and rejected workflows are excluded too. Finished tasks can remain eligible for the late-action facts described above, while further reassignment stages require an open task. Older tasks without the newer timing snapshot use a narrower warning/completion path; do not assume that every historical task has response-breach notices or escalation stages.
When work pauses or changes hands¶
An approval-authority problem can suspend the workflow. That path pauses the newer timing model on its open tasks and cancels the affected active approval tasks. When authority is resolved, replacement approval tasks can inherit saved timing and notification progress from the previous tasks by approval sequence. Other open paused tasks resume as well.
Resumption uses the saved business calendar. Deadlines still in the future at the pause move by their remaining business time from resumption. Deadlines already reached before the pause stay reached. Resolving authority does not reset every missed target or grant an entirely new policy window.
Ordinary reassignment keeps existing timing and first-response facts. Changing the responsible person does not give that person a new response clock automatically. A request returned for correction follows a different replacement-task path; the request guide explains its fresh timing where configured. These paths should not be interpreted as a general pause/resume feature available to every user.
Who receives an escalation¶
The newer processor starts with the requester and current assigned person. For unclaimed pooled work, it resolves the current eligible queue members. A configured escalation destination can add a person, position occupants or pooled-queue members. These are separate from the final reassignment destination: several people may be notified while only one person or queue becomes responsible.
A selected person must currently be an active staff member with WorkOS access. Positions resolve through eligible occupants and configured fallback positions. Queues must be active and their members within their effective dates. Approval-task reassignment must resolve to an individual. An alert's reason text does not choose a destination, and writing a person's role in the reason does not route the alert there.
Recipient lookup failure can defer the entire task check or stop progression at a particular stage. Support should investigate the actual staff, position or queue lookup. Replacing the target with an unrelated person simply to clear an error can change responsibility incorrectly.
What an email state means¶
| State or observation | What it establishes |
|---|---|
| Deadline passed | The task's saved target has been missed; no delivery result follows from this alone. |
| Notification requested | Background processing requested a channel action. Delivery may still fail or be suppressed. |
| Email disabled in the recipient's recorded preference | The email dispatch path suppresses the send. This does not cancel the deadline, escalation or other notification channels. |
| Provider accepted | The mail provider accepted the request. This does not establish inbox arrival or that anyone read it. |
| Delivery reported | A correlated provider event reported delivery. It does not establish that the recipient read or acted on the message. |
| Bounced or rejected | Delivery failed or the provider rejected the request; support must distinguish a temporary rejection from a permanent one. |
| Outcome uncertain | The external send may have happened. The system avoids automatically repeating it until the outcome is reconciled. |
The current dispatch path proceeds when the projected email preference is absent or enabled, and suppresses sending only when it is explicitly disabled. Preference editing and synchronization need their own connected account-guide verification; no new settings steps are asserted here.
An email contains the request reference, step and reached milestones, with a link to open the request. That link does not grant access to the request. Its correct destination and authorization still need to work in the delivered environment.
Investigate a missing or unexpected alert¶
- Establish the task and policy involved. Compare the saved deadline with the recorded first response or completion, rather than today's edited policy settings.
- Check the task and workflow state. A correction, cancellation or authority suspension can change whether processing should continue.
- Confirm the expected recipient and current assignment. A pooled queue, position and named person resolve differently.
- Distinguish a missing in-app notice from a missing email. Ask support to check the recorded email preference and whether an email request exists for that milestone.
- Have authorized support trace processing and provider evidence. A healthy scheduler proves neither that this task was swept nor that this message was delivered.
Provide the task/request reference, relevant deadline, approximate observation time and expected outcome. Avoid repeatedly changing the policy or recreating work to force another alert. For an uncertain provider outcome, support should reconcile the existing dispatch before attempting another send.
For managers and executives, these facts help explain operational exceptions. They are not evidence of employee intent, a contractual service guarantee or a complete performance measure. Business-calendar deadlines and elapsed-time reports can measure different intervals; agree the report's definition before comparing teams.