Request templates: forms, routes and versions¶

A request template defines the questions people answer, the workflow that handles their request, and the category and reference prefix used to identify the work. A well-maintained template gives requesters consistent questions and gives reviewers a defined responsibility. It does not guarantee that every assignment, external service or downstream action is ready in your environment.

Availability: The backend implements template creation, draft editing, publication, activation, deactivation and version history. The intended journey below follows fourteen Final Screens. The routed frontend currently uses example templates and local navigation. Connected saves and environment delivery have not been verified, and the creation and lifecycle gaps below still need resolution. Do not treat a preview success or a changed page as confirmation that a template was saved.

Find and review a template¶

1. In WorkOS, open Operations, then Request templates.
2. Enter a search term, select a status if needed, and choose Apply filters. Use Previous and Next for other result pages.
3. Choose Open template on the relevant row. Confirm the template name, selected version, status and linked workflow before changing it.
4. Use Handoff, Form fields, Workflow steps and Route rules to review the saved definition. The detail presentation is read-only; use Edit draft for an editable version.

When no filters match, broaden the search or return to Any status. A failed library read has a Reload action; wait for a successful read before trusting the available versions or actions. Restricted access requires the appropriate workspace permission. Hidden information is unknown, even where the current restricted design displays zero counts.

Some detail examples currently mix draft and active states, basic and custom setup, or unrelated workflow names. Do not use those sample combinations as business rules. Use the saved status and selected version; the lifecycle table below describes the implemented restrictions.

Prepare a new draft¶

The designed creation journey has two stages:

1. Choose Create template. Select Use starter for an enabled starter, then Continue, or choose Start from scratch.
2. At Confirm draft details, review the name, code, setup style, category, reference prefix and description. A starter supplies initial content; a capability-limited companion shows blank quick setup instead.

The saving step is still incomplete. The inspected starter-details screen has no visible final create button, while the capability-limited companion shows Create draft. The latter says the draft starts without fields or steps, but the implemented creation path requires at least one of each. Also, adopting a starter currently uses its registered content rather than saving the changes entered alongside that selection. These gaps must be resolved before this becomes a reliable connected creation procedure. Description is optional in the service even though the design marks it required; a reference prefix is required.

Once a draft has actually been saved, reopen it and check its content before editing or publication. Do not assume the starter-details preview saved your customized values.

What each starter supplies¶

The registered catalog currently contains the following four starters. All supplied questions are required. Starter availability depends on your organization's enabled capabilities; an enabled entry means you may adopt it, not that its assignments or business controls are ready.

“Line Manager Review” is the name of a work task in these starters; it does not itself establish a formal approval decision. Travel dates are initially a text answer, and quantities and advance amounts are generic numbers. The supplied forms do not establish a positive amount, a currency, a valid travel-date range or your organization's spending policy. Agree and verify those controls before rollout.

Laptop and office-supply starters support basic setup. Vehicle and travel-advance starters require advanced authoring as well as starter availability. All four start as internal service requests. None automatically reserves stock, pays an advance, books a vehicle or proves an external service has accepted the work. Review the saved questions, assignments, approval body, deadlines and completion outcome with the process owner.

Check the available setup choices¶

The editor combines choices from workflow configuration, the live organization structure, active staff and existing approval bodies. A choice appearing in a list does not prove that the selected setup can run. Some workflow controls also exceed the capabilities of basic setup; follow the actual authoring and runtime limits.

Approval-body options include readiness and membership information. Check that the body is active and has the appropriate voting members for this process. Seeing a body here does not give you permission to manage its membership. Deadline-policy choices include active policies; review the selected policy with the process owner rather than inferring its timings from its name.

People, positions and queue choices can be incomplete. In the current implementation, some lookup failures are returned as empty choices, so an empty selector does not prove that your organization has no staff or structure. Queue choices are derived from positions in the live structure and do not independently prove that a queue is ready to receive work.

If an expected choice is missing, preserve any visible error, check that the relevant organizational configuration exists, and ask an administrator or support to investigate. Avoid replacing an intended assignment with an unrelated option just to save the draft. The connected editor still needs distinct loading, empty, failed and unavailable states; no verified retry control is assumed here.

Edit a saved draft¶

1. Open the unpublished draft and choose Edit draft.
2. Review the shared draft details, then Form fields. The design offers Add field, Save draft and Discard changes. Check each field's label, type, required setting, order, choices and table columns.
3. Review Workflow steps. Use the intended Add step and editing controls to define the responsible work and approval steps. Check assignments, acceptance, rejection, correction and field access together.
4. Where advanced authoring is available, review Route rules. The design offers Add route, Add assignment rule and Add approval rule. Confirm the destinations, conditions, responsibilities and approval method before saving.
5. Use Save draft and verify the saved definition before moving to publication. Discard changes is the intended way to leave unsaved edits; connected discard behavior and confirmation still require verification.

The current design does not yet establish every field editor, confirmation or saved/error result. Changes must retain the complete form and workflow rather than silently dropping content outside the selected tab. The draft detail shows Rename draft and Publish draft; complete rename, delete, activation, deactivation and new-version companions remain design follow-up. Follow the lifecycle rules below when those connected actions become available.

Handoff belongs at workflow completion. The current example wording “After submission” must not be read as an implemented immediate transfer. A destination must also be registered for the running workflow; permission to configure a custom destination does not make it ready to receive work. An approval count also differs from the number of branches that must finish before a route rejoins.

Who prepares a template¶

The process owner decides what information is needed, who does the work, which decisions are required and how exceptions should be handled. An administrator with template-management access maintains the definition. Permission to view templates is separate from permission to change them. Selecting an approval body uses existing governance choices; it does not create or change that body's membership.

Before preparing a template, agree its purpose, clear name and description, category, reference prefix, required answers, responsible positions or queues, approval body, correction rules and intended completion outcome. Ask a representative requester and reviewer to check the wording. Confirm that assignments can resolve to the right people and that any later document or external-work step has an owner.

For business leaders, versioning provides a way to introduce changes without rewriting a published form in place. Adoption still requires ownership, training and an observed end-to-end result. Template counts and preview examples are not measures of usage, productivity or return on investment.

Draft, active and inactive have different meanings¶

Publishing or activating a version deactivates other active versions of the same template family. Version history is therefore important when changing which form accepts new requests. Activating an older published version is a change to new-request availability, not an automatic rollback of work already submitted.

Inactive does not mean editable. Editing requires an unpublished draft. An unusual inactive template that was never published can need support investigation; do not assume that deactivating a draft is a way to save it for later editing. A deleted newer draft can also prevent starting another draft from an older version. Keep the existing version references when asking for help.

Each submitted request records the selected template and linked workflow identity and version. These template-maintenance operations do not move existing requests to a replacement version. Review requests already in progress separately before changing an operational process.

Basic and advanced authoring¶

Basic authoring builds a forward sequence of work and approval steps. It requires at least one form field and one step, and supplies the route between those steps and the finishing step.

A work step can require acceptance before work proceeds. Basic approval steps cannot use that acceptance setting. Rejection and return-for-correction are separate choices. When return is enabled in basic authoring, the requester can revise all the form's defined fields. Explain this to process owners before enabling return.

Advanced authoring can express richer routes, conditions, assignment behavior, approval rules, timing policies, parallel work, subworkflows and handoff configuration. Those controls require careful validation and appropriate capabilities. Branch-completion rules and human approval thresholds answer different questions; consult workflow definitions and approval decisions.

A saved authoring mode and compatibility with the basic editor are different facts. A template with handoff or richer workflow structures may not be suitable for the basic editor. Do not simplify an existing process by dropping fields or routes that the editor cannot represent.

Starter templates and commercial access¶

A starter supplies a predefined form and route that can be adopted as a new draft. Adoption uses the starter's definition; it is not a live subscription to later starter changes. Review the resulting draft before making it available. Do not assume that extra text entered alongside a starter selection replaced the starter's saved content.

The service reports whether starters and advanced authoring are enabled for the tenant. Individual starters also indicate whether they support basic authoring and whether they are enabled. Some require advanced authoring. A listed starter can therefore be unavailable for your current configuration.

Use the current capabilities and returned action explanation rather than a plan name alone. A commercial capability, permission to manage templates and validity of the selected draft are separate requirements. This page does not establish pricing or guarantee a feature for every tenant with the same displayed plan label.

Recover from a plan or authoring restriction¶

If the response says that your current plan does not include the selected feature, ask an organization administrator to review the required capability and current available plans. Starter adoption and advanced authoring are separate capabilities. An advanced starter requires both; access to advanced authoring alone does not grant starter adoption. Keep the selected starter and the returned explanation when seeking help.

A plan change is not the remedy for every refusal. Missing access information needs investigation, and an advanced-only starter cannot be used through the basic authoring path even when the organization has the required capabilities. Management permission and a valid draft remain necessary. Do not repeatedly resubmit the same change or assume that a different plan label will fix a validation problem. A listed starter or an example upgrade prompt is not confirmation of access, a purchase or a saved draft.

Form fields and answer rules¶

Give each field a clear label and stable identity, choose its type, set its order and decide whether it is required. Field identities must be unique. Choices and table columns need their own valid definitions.

Required means the answer cannot be absent or null. A required table currently accepts an empty set of rows, so it does not enforce “at least one item.” A process that needs minimum rows, a positive amount or another specific business constraint needs an explicitly verified rule. File attachments use the document flow.

Initial submission rejects unknown field and table-column identities. When changing a draft, review every field, allowed choice and required column together with the workflow. A saved update replaces the managed definition; it is not a promise to merge omitted form or route content automatically.

Browsing and checking the selected version¶

The administration list can filter by status and search names, descriptions, categories, reference prefixes and starter keys. It shows versions rather than promising one row per template family. Deleted templates are excluded from ordinary browse results. No matches and an empty page beyond the available results have different meanings; return to an earlier page or clear the relevant filters.

Open the full definition before deciding it is ready. Review its form fields, workflow steps, route rules, assignments, approval rules, handoff and version history. A row alone does not contain every field needed to decide whether publication or activation is possible. Version numbers are whole numbers for the template and its linked workflow; they are not decimal software-release labels.

Handling a failed or uncertain change¶

Support needs the template name and version, approximate time, attempted action and visible message. Provide sensitive form contents only through an authorized support channel when necessary. Remaining screen companions, connected saves, concurrent changes and recovery in a deployed environment still need verification.