Requests, tasks and workflow execution¶
Requests turn a recurring business need into a recorded piece of work with a defined route. A requester chooses a request type, supplies its information and submits it. The workflow assigns work, collects decisions and can return the request for correction or hand the approved information to another business area.
Availability: The backend contains request submission, personal history, search, task decisions, corrections and workflow execution. The frontend is still in progress; the inspected requester pages render examples and navigation rather than establishing connected submission or decisions. The guide describes the intended Final Screens journey and identifies material differences. Environment delivery and audience acceptance remain unverified. This is a documentation draft.
What the terms mean¶
| Term | Meaning |
|---|---|
| Request type or template | The reusable form, its category and reference prefix, and the workflow definition linked to it. It determines the questions asked when starting work. |
| Request | One submitted instance of that form and workflow, with its own reference, requester, answers and history. |
| Workflow definition | The reusable steps, assignments, decisions and handoff rules. Read workflow definition and publication for its lifecycle. |
| Task | One piece of work created while a workflow runs. A request can have several tasks and several people involved. |
| Approval | A decision process attached to an approval task. One person's approval may leave other required decisions outstanding. |
| Correction | A request returned to its original requester to revise permitted answers and resume the existing workflow. |
| Handoff | Approved request information prepared for another business area after workflow completion. Its delivery and the other area's progress require separate evidence. |
When approval authority changes¶
An authority change can refresh pending approval routing, replace open tasks or suspend affected work until the required authority is resolved. Earlier resolved decisions remain recorded, and replacement tasks can inherit existing timing obligations. Read approval work after authority changes before interpreting a cancelled task, a changed reviewer or a resumed deadline. This background process does not establish that a saved body change has already reached every request.
Export, deletion and retained history¶
Cancelling a request or deactivating a template does not erase the organization’s history. The workflow lifecycle guide explains the selected export records, omitted related details, deletion scope and the evidence needed to interpret a participant result. An exported form or document-bundle header does not establish a complete or restorable package.
Requests prepared with the assistant¶
The backend also contains an assistant-facing route to find a request type, obtain its current questions and prepare a submission for review. Connected assistant submission remains unverified in this documentation draft. The ordinary request guide remains the documented Final Screens journey; this capability does not establish a new chat control or make every request type available through the assistant.
A request type can change between selection and submission. An exact review needs the current questions and answers, the person submitting, and any organizational position that affects the request. If material information is missing or has changed, the earlier review is insufficient. See governed actions and approvals for the distinction between preparing work, approving a proposed change and confirming its result.
Submitting through an assistant still starts the owning business workflow. It does not approve later tasks or confirm a receiving team's work. If the result is uncertain, retain the original conversation and request details and reconcile saved state before another submission. A missing confirmation does not prove that nothing was saved.
Understanding workflow assistance¶
The backend also contains reads for finding requests, understanding assigned work and obtaining context before a decision. Their connected use through the assistant remains unverified: the current path has availability and missing-detail constraints. Treat the following as an explanation of the underlying work, rather than a promise that every question can already be answered in chat.
| Information | What it describes | What it does not establish |
|---|---|---|
| My requests | Requests submitted by the current person, starting with recent submissions | Every task assigned to that person, or an assurance that their requests are on time |
| Pending approvals | Assigned request tasks with a decision still pending for the current person | Every item in the work inbox, a completed decision or permission to approve |
| Work inbox | Current assigned work; returned work can still appear | That each item can be completed immediately or has the same decision requirements |
| Shared queues | Pending work in queues the person is currently eligible to use | That the person has claimed a task or that a queue result reserves it |
| Request status and workflow detail | Saved work, its current step and available source context | Completion by a receiving team, a complete account of parallel work or an unchanged future state |
| History and documents | A selected history and information about document collections | Every discussion or file, permission to open a file, or evidence that a signature was applied |
| Request overview counts | Current aggregate measures across the source's request population | A personal work list, a report for a selected period or an employee-performance score |
These selections answer different questions. A request you submitted can be waiting with someone else. A task in a shared queue can remain unclaimed. A returned item can appear in assigned work while being excluded from pending approvals. Comparing those counts as though they describe the same work can be misleading. Warning and overdue measures can also overlap the ordinary request statuses; adding them to status counts can count work twice.
My Day is a separate personal starting point. Its current-day selection, pool eligibility and completeness limits do not turn request search or aggregate counts into the same view. Use the owning WorkOS page to check the selected request or task, its current assignment, exact deadline, saved answers and permitted next action.
An assistant response may lack details needed to make a decision. Do not treat a missing amount, deadline, answer or count as zero, an empty value or confirmation that no work exists. A short result can be bounded, and the current workflow-assistance path does not establish a usable way to continue every list. An unavailable answer is different from a successful check that found no matching items.
Reading work does not claim, approve, reject, edit or submit it. Before making a change, review the current source and follow its specific task or decision flow. If a previous action has an uncertain result, reconcile that original action before repeating it. Keep the workspace, request reference, task and time for support; avoid sending confidential answers or document contents in an ordinary support message.
Managers and executives should use these summaries as prompts for inspection, with their selection and freshness limits understood. Missing detail is not proof of spare capacity, an absent obligation or a service-level result. Read-only assistance can still consume the organization's AI credits through the enclosing conversation; it does not imply free usage.
Responsibilities¶
Requesters supply accurate information, retain the saved reference, monitor progress and respond to correction notes. A request submitted on behalf of a team still records the actual submitting user; the current resubmission path requires that original requester.
Reviewers read the saved request and their specific task before deciding. They may be allowed to amend selected answers, return the request or reassign work. A button or a search result does not itself establish authority. Viewing, submitting, completing, approving and intervening are separate permissions.
Managers and process owners define who is responsible for each step, which information can change, what rejection means and when another team takes over. They should distinguish one completed task from a completed request. An approval can remain pending while other participants decide.
Executives can use the feature to understand ownership, progress and exceptions across repeated work. The existence of a workflow does not prove a contractual turnaround time, successful purchasing, regulatory compliance or financial benefit. Adoption requires suitable templates, maintained staff and queue assignments, trained reviewers and verified connected delivery.
Tenant administrators manage access and coordinate template and route setup. Platform staff and support distinguish an unavailable frontend, an access issue, an invalid form, unresolved routing and a downstream delay. A support role does not automatically grant permission to decide a tenant's request. Engineers, designers and operators have a private integration reference in GitHub.
From submission to outcome¶
- An authorized user chooses an active template. Its linked workflow must be published before submission can start.
- The service checks the submitted answers against the template, issues a request reference and starts the workflow with the submitting identity and optional source position.
- The route opens work or approval tasks. Assignments, parallel work and required decisions determine what can advance.
- A reviewer may approve, reject, complete an assigned step, reassign work or return the request where permitted. These actions have different meanings and permissions.
- A returned request can resume after its original requester resubmits the allowed changes. The service retains revision history and creates replacement work for the returned step.
- At the completion boundary, a configured request handoff can prepare the current approved information for another business area and put the request into an external-wait state. Without that handoff, the workflow can complete locally.
The request retains its template and process identity/version information. A new template version is not evidence that an existing request has switched routes. The template lifecycle explanation covers creation, basic and advanced authoring, publication, activation, versions and answer rules. The administration screen journey and connected saves remain under verification.
Understanding a request reference¶
A reference helps you find and discuss a saved request in the correct workspace and request type. Numbers may be reserved before all submission steps finish, and some reserved numbers may remain unused. A gap in the sequence can therefore occur without a missing or deleted request. Reference order also does not establish the order in which work was approved or completed.
Use the saved request and its status to confirm the outcome. If submission takes longer than expected or the response is lost, check whether the request was saved before submitting again. Retain the reference when available, the attempted request type and the time for support; do not infer success or failure from the next number you see.
Read status in context¶
| What you see | What it means for the reader |
|---|---|
| In progress or waiting for approval | Work is active or required decisions remain. Open the detail to identify the current task; a single summary step cannot explain every parallel branch. |
| Waiting for a pooled queue | Work needs to be taken through the eligible shared-queue path. Queue visibility and claim permission need to be checked separately. |
| Returned | The original requester needs to review the correction note. This is a continuation of the same request. |
| Waiting for external action | Another operation is outstanding. Check the saved downstream reference and update time when available; the label does not prove that the receiving team completed its work. |
| Suspended for an authority issue | The approval authority needs attention. An administrator or process owner must reconcile it; repeatedly submitting the same decision is not a remedy. |
| Rejected, cancelled, closed or completed | These are distinct terminal outcomes. The request-mutation guard prevents ordinary further changes. Completion does not independently certify every downstream business result. |
Warnings, overdue indicators and age answer different questions. Age describes elapsed time since creation, ending at completion when recorded. A due warning or breach comes from task timing. Neither proves the cause of delay. A missing due value must not become an invented deadline.
Business rules and limits¶
- The template supplies the form. Required answers, value types, allowed choices and table columns matter; unknown fields are rejected at initial submission.
- New requests currently take their heading and description from the template. The separate title and details fields shown in the design do not establish that a custom request heading was saved. A template can also ask for a title or description as one of its form answers.
- Correction and reviewer amendments are limited to the fields allowed by the current step. Unchanged answers must be preserved when saving an amended form.
- Returning a request cancels its other active tasks. Resubmission reopens the returned step's work and re-evaluates assignments; it does not promise to restore every cancelled parallel task unchanged.
- A personal history list, an approval inbox and a broader search are different views. The search summary describes the overall request workload and is separate from the filtered result list.
- Saving a personal unfinished draft, editing freely until the first approval, making bulk decisions and paging through request lists have not been established as available operations in this request flow.
Permissions and template-authoring capabilities are separate concerns. This draft does not establish a price, a universal plan entitlement for every request type, or a billing exemption. Administrators must confirm the applicable workspace access and configuration.
Rollout and support¶
Before introducing a request type, check the form with a representative requester, its route with the responsible manager, and correction/rejection with a reviewer. Confirm staff and queue resolution, any required document handling, downstream ownership and the environment in which people will use it. Use the task guide for the reader walkthrough.
For a failed or uncertain action, retain the request reference, task name, time, visible message and what you attempted. Refresh saved state before retrying. Share only the information needed by your authorized support channel. Do not send credentials or another person's sensitive form answers.
This draft covers the requester lifecycle, personal work and pooled queues, manual reassignment, escalation and cancellation, activity history and comments, and workflow document bundles. The guides explain intended steps, actual consequences, access and recovery. Escalation changes task ownership; cancellation ends the local workflow without proving reversal of work already dispatched elsewhere. Activity explains recorded events and task discussions, with explicit limits on timing, access and comment revisions. Documents distinguish uploaded files, saved attachments, collated collections, task completion and governed record signing. Remaining template metadata/starter suitability, complex execution recovery, automatic intervention, remaining activity producers, complete shared-document flows, signing recovery, receiving-service handoff delivery, retention and complete operational boundaries remain required follow-up coverage within WOS04. Their existence is not treated as completed documentation or accepted delivery.
The assigned record-signing guide now covers readiness, reviewing and placing a saved signature, submitted versus applied results, fresh restart and support holds. Remaining signing work includes complete shared-session mechanics, legacy callers, hosted recovery/concurrency and delivery; those limits remain distinct from the documented intended task journey.
The document-approval guide explains your pending approval inbox, configured due timing, record and nonrecord review, decision history, optional-reason rejection and the approval rules that determine whether more decisions are needed. Approval is separate from signing and from returning a request for correction. Connected delivery, exact action availability and wider authority/routing recovery remain open.
The completion-handoff explanation distinguishes the completed internal route from work owned by a receiving team. It explains saved references and status snapshots, uncertain delivery and cancellation. A completed local request does not establish that the receiving work has finished.
The runtime execution explanation covers route choices, supported parallel joins, automatic cancellation and the current subworkflow-tracking limit. Saved conditions do not establish automatic condition evaluation, and a subworkflow marker does not establish child execution.
Read SLA policies, deadlines and escalation to understand response/completion targets, business calendars, saved task timing and the effect of policy changes.