Submit, review and correct a request¶

Use Requests to start work from an agreed form, follow its progress and handle a decision or correction assigned to you. This guide follows the intended WorkOS Final Screens. The frontend is still being connected. Example pages and their navigation do not prove that an action saved real work. Confirm availability with your workspace administrator before using this as a production procedure.

Before you begin¶

Administrators and process owners can read request-template forms, routes and versions for preparation, intended administration steps, lifecycle rules, recovery and the remaining creation and editing gaps.

For decisions reached through Workflows → Document approvals, use the assigned approval guide. It covers that inbox's search, due timing, record documents and decision outcomes. The request-specific steps below cover the Requests journey.

Use the correct workspace and signed-in account. You need access to view the request types and a separate permission to submit. Review and intervention actions have their own permissions. A visible request is not permission to approve it, and external participation does not automatically expose the internal catalog.

Have the information required by the selected request type. If your organization uses a submitted-from position, identify the appropriate position before sending the form. An administrator maintains the template and route; choosing a position does not make you a different signed-in person.

Choose the right request type¶

1. Open Requests from WorkOS and select Catalog.
2. Compare the request types, categories, live status and reference prefixes. The examples in a preview are not an inventory of templates available in your workspace.
3. Select Open template for the type that matches your work.
4. Review its saved basics and linked workflow/version. The detail companions are Handoff, Form fields, Workflow steps and Route rules. They explain the form and route; they are read-only in Requests.
5. Open New request when the type fits your purpose. If it does not, return to the catalog or ask the template owner for help.

An active template can appear in the catalog even if its linked route is not currently startable. Submission still checks that the workflow is published. If no suitable type is available, do not substitute an unrelated type merely to get the work into the system.

Current design difference: the template handoff example says that information moves immediately after submission. The inspected request runtime initiates its configured handoff at workflow completion. Use that completion rule when explaining when the receiving team can expect the information.

Complete and submit the form¶

1. In New request, select the Request type first. Its form determines the questions and any repeatable table rows.
2. Choose Submit from position when applicable to your route.
3. Fill in the generated request fields. Use the offered choices for a choice field, a valid number for a numeric field and a date for a date field. Required answers cannot be omitted.
4. For a table, complete each row using its defined columns. Use Add another line item when the form provides it and you need another item. Review quantities and descriptions row by row.
5. Review the selected template and all answers, then select Submit request.
6. Check the saved result and open My requests to locate the request. Retain its reference and confirm that the details belong to the work you intended to start.

The design also shows Request title and Request details outside the generated form. For now, the saved request's heading and description come from its template. If the template asks for a title, business need or description as a form answer, complete that answer. Do not rely on the preview's custom heading as evidence that a separate title was saved.

The intended final design shows a submit action on the form. Additional confirmation and submitted-state pages in the frontend are previews; their wording is not evidence that submission happened. Saving an unfinished personal draft has not been established as available. Before leaving an unfinished form, follow your organization's approved handling of unsaved information.

If submission returns a validation error, correct the identified answer and review the form again. If the template or route is no longer usable, ask its owner to resolve that condition. If the response is uncertain, first look for the request in My requests and open its saved detail. Do not start a second request simply because a spinner or connection stopped.

Follow your submitted request¶

1. Open My requests.
2. Find the reference, request type and current status, then select Open detail.
3. Use Details for the saved request facts and answers. Compare the current step, requester and update time with the work you expected.
4. Use Task to see whether there is something you can do. A request can be visible while another person owns its active work.
5. Use Activity for the designed history view when that connected capability is available. The activity and comments guide explains filters, detail, workflow-wide updates, shared task discussions and delayed history. Its step-by-step screen intake covers the workflow Activity family; a request page's connected composition still needs verification.

If several active tasks belong to you, the request detail may stay read-only until you open a specific task. Open that assigned work instead of assuming that a read-only detail means the request has finished.

The current personal history list does not include every downstream or due detail shown in the examples. Open the saved detail/status view for available information. A downstream reference and its last update describe the latest recorded information; a missing value does not establish failure or completion.

Find requests across the workspace¶

Open Search when your role permits broader request discovery. The intended screen combines text search with starter, request-type and status filters. Select Search, then Open detail for the relevant result.

Text search currently matches the reference, template title and workflow title. Choosing a starter or status applies a separate filter; entering a person's name is not a promise of searching every form answer or owner display name. Paging through these results has not been established as available.

The Request summary above the results describes the overall request workload. It does not become a summary of your filtered rows. Keep that distinction when reporting counts to a manager. Read overdue indicators alongside the actual task and due information; a count is not a diagnosis of why work is late.

Review an approval¶

1. Open Approvals and identify the request and review step. This inbox is built from pending approval work assigned to the current user.
2. Select Review and read Details before acting: the requester, saved answers and any available timing or downstream facts.
3. Open Task, then Approve or reject when that action is available for this task.
4. Review the available route choice. A single choice may already be selected. Use only the choices supplied for the current task; do not invent a next step when none is available.
5. Add an optional decision note when it will help the requester or next reviewer. Change only the reopened fields if this approval allows amendments.
6. Choose Approve request or Reject request, as permitted, and inspect the refreshed saved outcome.

An approval records your decision; the route may still need other decisions. Rejection availability depends on the step, and the approval rules determine the resulting outcome. Returning for correction is a separate action when the requester should revise the work.

The decision note is optional. Current design difference: a companion screen keeps decision buttons visible when it says no transition is available; their presence is not proof that the task can advance. If no valid action is offered, ask the process owner to resolve the route instead of repeatedly attempting the decision.

Complete an assigned work step¶

For ordinary assigned work, open the request's Task area and choose Complete when offered. Read the current step, finish the required work and review the available transition before selecting Complete task. Approval tasks use the approval action described above.

A pooled task must be claimed through the eligible queue path before completion. Follow Find and take ownership of workflow work for the intended claim steps, membership rules and recovery. A task assigned to someone else is not yours to complete. If an action was already completed or cancelled while you were reading, refresh the request and inspect its latest state.

The design includes a conditional Sign document action for linked record work. Full signing-session instructions and outcomes are still being reconciled. An ordinary workflow attachment is not proof that a signable record exists. A submitted signing operation can wait for a separate records action; do not describe it as a completed signature merely because the task action returned.

Reassign an approval task¶

When authorized reassignment is available, open Task → Reassign. Choose the Next reviewer, optionally add Position context, and write a short Handoff reason if useful. Select Reassign task, then verify the saved assignee and current task state.

An approval task needs a named reviewer. Position context does not replace that person, and the intended approval screen does not offer a shared queue as the primary target. General work-step queue reassignment is a separate runtime path. If the right person is unavailable, contact the process owner instead of choosing a convenient but unauthorized reviewer. The manual intervention guide explains workflow reassignment, escalation, cancellation and their recovery limits.

For work that needs files, follow the workflow document guide. It explains the intended Add document entry, checking the saved collection, governed viewing and recovery. Uploading, attaching and collating a file collection do not themselves complete the task or sign the linked record.

Return a request for correction¶

1. Open the relevant active task and choose Return for correction when your permissions and the step allow it.
2. Enter the required Correction reason. State exactly what the requester needs to change and why. Refer to the affected form answers in ordinary language.
3. Select Return for correction and verify that the saved request is returned.

Returning affects the request, not just the note: the backend marks the selected task returned and cancels other active tasks. Explain that consequence to process owners using parallel work. If several people are working on the request, coordinate before returning it.

The correction note does not itself change which fields are editable. The step's configured requester-revisable fields control that. If the needed change is outside those fields, ask the template/process owner to resolve the restriction.

Correct and resubmit your returned request¶

1. As the original requester, open the returned item from My requests.
2. Read What needs to change, including the return note and who returned it.
3. Open Task → Update and resubmit. The intended correction form shows only the reopened fields; review the other saved answers in Details.
4. Make the requested changes in those reopened fields. Preserve the other answers. If no needed field is available, stop and ask the process owner to reconcile the correction request.
5. Select Resubmit request, then verify the same request reference and its resumed state.

The system keeps the original request and its revision history. It resumes work for the returned step and resolves its assignments again. A still-valid manual assignment can be retained; otherwise the route can assign a different person or queue. Replacement tasks receive fresh timing where configured. Do not assume that the previous reviewer or every cancelled parallel task is restored unchanged.

Current design difference: support text mentions a correction form that opens next, although the inspected screen already contains it. Follow the correction form within Update and resubmit. Starting a new request is not the correction path for the existing item.

When something prevents progress¶

Read when a request passes to another business area to distinguish waiting, a recorded handoff and completion of the receiving team's work. It explains why a saved status may be a snapshot and why local cancellation does not reverse a delivered action.

Provide support with the workspace, request reference, task, approximate time and visible message. Include only the relevant information you are allowed to share. Managers should use the overview to explain ownership, status and rollout limits to their teams.

For the effect of route choices, parallel completion and subworkflow tracking, read how requests move through their route. Check these runtime limits with the process owner before relying on an automated branch or child workflow.