Skip to main content
Requests gives each member one place to see formal decisions waiting for them. A request can ask for an approval, a correction, an acknowledgement, an escalation, or another organization-defined outcome. An action may require a cryptographic signature, but signing is a requirement of that action rather than a separate type of work. Use Requests when the organization needs a durable decision record. Use Tasks when somebody needs to perform operational work. A task can collect a missing document or arrange an inspection; a request records the formal outcome after the evidence is ready. KayanOS Requests workspace showing a corrected vendor approval round and three visible response actions.

​
Understand the four views and urgency

Open Requests from the navigation. The queue keeps the selected request and its review evidence together. Needs you groups its rows as Overdue, Due today, Due soon (within seven days), and No pressing due date. Each row shows its source, later-round badge, signature requirement, stage dots, and whose turn it is. The tab count is highlighted when any loaded request is overdue. Other views remain flat lists. Search and filters narrow the loaded view by text, source, due state, requester, and whether an action requires a signature. Filtering does not change eligibility or access. If a request is absent, first confirm the selected view and filters, then check whether its current stage is assigned to you.

​
Follow a request you created

In Created by you, the progress bar shows completed stages and the blocking line names the unresponded members in the current available stage. It is progress information, not authority to respond for them. The request creator can use Send reminder on an active request. KayanOS sends it only to unresponded members of the current available stage and enforces one manual reminder per request every 24 hours. A reminder does not change the due date, stage, eligibility, or outcome. The creator can also cancel an active request; use that only when the request itself should end, not as a substitute for correcting and resubmitting a form round.

​
Review before responding

Select a queue row to open the review workspace. Read the header, due state, source, requester, and round. For Round 2 and later, begin with What changed since your last review. It compares approval-relevant values from the previous immutable snapshot with the current one. Continue through:
  1. Request details — the canonical subject snapshot covered by this round.
  2. Evidence — attachments supplied for the decision.
  3. Approval path — ordered stages, completed stages, and the current stage.
  4. History — recorded actions, comments, signing capacity, response time, and signature proof where required.
Do not assume a prior-round approval covers the new round. The round badge, change summary, and history make that boundary explicit. For a request you previously answered, a later round places the superseded-response warning and change comparison before the evidence. Start with that delta, then review the current snapshot in full; the comparison does not replace reviewing current evidence.

​
Complete the evidence gate

Response actions stay locked until the current evidence is reviewed. Scroll the inline form snapshot to the end. Open or mark every additional attachment as reviewed. If the snapshot cannot be previewed inline, use Open in new tab; opening it counts as reviewing that snapshot. A load failure stays locked until the snapshot loads successfully. A request with no documents unlocks from its inline details. Review progress is local to the current browser session, but the server still checks the attachment acknowledgement submitted with the response. Unlocking buttons is not proof that the content is correct, and it does not grant access to an attachment’s source record.

​
Review the versioned PDF snapshot

For a form-backed round, the evidence area can provide a versioned PDF snapshot of the exact submitted state covered by the request. Open it from the current round, confirm the request family, round, and document version, and compare it with the visible change summary before responding. The PDF is immutable review evidence; downloading it does not make it the live form or grant access to its source files. If the initiator corrects an approval-relevant value, the prior PDF and responses remain attached to the prior round. The corrected submission must create a new round and proof version before it can receive a new decision. Do not approve changed content from an older download, even when the title and request reference look the same.

​
Choose an action

Every action configured for the request is visible in the sticky response area after the evidence gate is complete. Each button states whether a signature and comment are required. The confirmation dialog then contains the reviewed-evidence summary, comment, signing capacity when needed, and confirmation control; it does not repeat the evidence viewer. Labels can be organization-specific; the underlying action key and outcome key remain stable audit identifiers. An action has two independent effects:
  • continue satisfies the current stage and opens the next ordered stage. At the last stage it completes the request.
  • complete ends the request immediately with that action’s outcome.
A request might use Approve, Request changes, and Escalate, or another small action set appropriate to the service. Do not infer behavior only from button color. Read the outcome and requirements in the confirmation dialog. Stages always use any one participation. When one eligible assigned person responds, that stage is satisfied and the other assignments for the stage close. KayanOS then opens the next ordered stage. There is no “all assigned people must respond” mode.

​
Respond without a signature

For an unsigned action, enter a comment when required and confirm the action. Optional comments are still useful when the reason will help a later reviewer. The response is recorded against the exact request family, round, stage, action, outcome, subject hash, evidence list, and signing capacity value. No member-key signature is created. If the request changed or another eligible reviewer completed the stage first, KayanOS rejects the stale response. Refresh the request and review its current state before trying another action.

​
Respond with a signature

A signature-required action clearly shows Signature required before you open it.
  1. Review and acknowledge each attachment presented by the signing flow.
  2. Choose the signing capacity allowed for the current stage. This can be personal or an active position capacity.
  3. Select the approved member key file for this browser tab.
  4. Enter the six-digit member-key PIN.
  5. Confirm the action.
KayanOS signs a canonical versioned payload containing the request family, round, stage, selected action and outcome, comment, subject snapshot hash, source proof, evidence hashes, and signing capacity. The server verifies the active credential and stores the signature proof with the response. Never share a key file or PIN, and do not sign through a capacity that does not match the service policy.

​
Request changes and resubmit

Suppose a form request offers Approve and Request changes. A reviewer chooses Request changes with a required explanation. That action completes the current round with the needs_changes outcome. The initiator then edits the form. When the form’s scope-invalidation setting is enabled, changes inside the configured approval scope make an active round outdated immediately. Old responses remain visible and unchanged because they describe the old snapshot. When the setting is disabled, those edits preserve the current approval and no resubmit action appears. After corrections, the initiator chooses Resubmit for approval. Resubmission is explicit:
  • KayanOS compares the new approval snapshot with the prior snapshot.
  • If there are no approval-relevant changes, resubmission is rejected.
  • If there are relevant changes, KayanOS creates Round N+1 in the same request family.
  • The new round links to the previous round and stores a deterministic change summary.
  • Current stage selectors are resolved again, then approval restarts from Stage 1.
This model preserves history without letting old approval proof silently authorize changed content.

​
Create a direct request

Authorized members can choose New request. The creation page keeps all configuration sections visible:
  1. describe the request and timing;
  2. capture the subject and optional evidence;
  3. add ordered approval stages; and
  4. define response actions.
For each action, choose a preset or a custom action, set the localized label, review the stable action key beside it, and choose the visual tone, continue or complete, signature requirement, and comment requirement. KayanOS assigns the action’s stable outcome identifier from the chosen preset or custom-action slot; there is no separate outcome-key field to complete. Keep the action and outcome identifiers stable after requests use them, even when a visible label needs correction. Keep the set small enough that reviewers can understand every option at once. Attachments are optional. Before creation, the summary shows the number of stages, actions, and signature-required actions.

​
Compatibility and permissions

Existing signing-request links continue to open the Requests experience. Legacy signing rules retain their allowed decisions and signature proof. Existing SOP approval records retain their compatibility detail while new SOP approval actions can create unified requests. The technical permission identity remains signing_requests during rollout, even though navigation says Requests. Creating, viewing, responding to, signing, and managing requests still require the assigned organization verbs and scope. Being named in an old round does not grant access to a new round unless the current stage resolves to you again.

​
Safe testing

Create a non-production request with two stages, a snapshot plus one extra attachment, and two actions: signed Approve with continue, and unsigned Request changes with complete and a required comment. Confirm that one response completes each stage, all actions remain disabled until the snapshot and attachment are reviewed, and the second stage opens only after the first. Then request a change, edit one in-scope value, and resubmit. Verify that Round 2 shows the exact change, starts from the first stage, and retains Round 1 responses. Finally, test an out-of-scope presentation change and confirm it does not create an approval-relevant resubmission. Repeat the scoped edit with invalidation disabled and confirm the current approval remains active without an outdated warning or resubmit action. Change signer rules and confirm ordinary saves still preserve the request; explicitly prepare again to apply the current signer rules. Set the preparation-visibility expression false for the initiator and confirm Prepare and Resubmit/Reprepare are absent while reviewer response and signer controls remain available to their eligible users. Attempt the prepare action directly and confirm the server rejects it. Set the expression true again and confirm an existing outdated round returns to the reprepare path. As the creator, confirm Created by you shows the blocking stage and member, then send one reminder. A second reminder inside 24 hours must be throttled. Confirm a non-creator cannot use the reminder endpoint and that no completed or cancelled request can be reminded.

​
Troubleshooting