Approvals

Workflow Agent can render approval packet previews for actions that would require review before execution. The current controls do not create signed decisions: no approval has been requested, granted, or denied, and the Approve, Reject, and Request changes actions are disabled. Use the surface to inspect why a gate exists and what information a future reviewer would need.

Approval packets

An approval packet is assembled from the workflow draft and simulation context. It can summarize the proposed action, the app and route involved, the reason approval is required, and the supporting preview evidence. Its purpose is to make a consequential step reviewable before any external effect.

The packet remains a preview. It does not enroll a reviewer, start a decision deadline, or change the workflow’s execution state. A packet may exist even when the route itself is not configured, because the builder can identify governance needs while other prerequisites remain unresolved.

Keep approval packet previews distinct from signed agent-run approval records. Batch 02 runtime approvals can have their own decision and state model; the Workflow Agent page does not reproduce that behavior.

Reviewer actions

The visible reviewer controls are disabled. Selecting or reading an action label does not persist a decision, resolve a gate, or authorize execution. Documentation should therefore explain what the controls represent without telling the reader to click them as a completed procedure.

Conceptually, approval would allow the proposed action to proceed, rejection would keep it blocked, and a request for changes would return the draft for revision. In the current preview, those outcomes are informational only. The gate remains unresolved.

If the packet exposes a sensitive action, verify that the draft still shows the approval requirement after editing. Do not remove the gate to make a simulation pass. A preview that pauses at approval is a correct and safer result.

Evidence

Evidence helps a reviewer understand how the packet was produced. It can include the workflow definition, simulation summary, route-readiness result, missing-credential state, policy outcome, and the specific step that triggered review.

Evidence is not the same as an artifact, output, audit event, receipt, or history record. In this surface it supports a preview packet; it does not prove an external action occurred. Seeded or fixture-backed values should be labeled as examples rather than as observed production facts.

Useful evidence is narrowly related to the decision. Avoid placing secrets, raw credentials, unrelated personal data, or speculative claims in the packet. When an item is missing, leave the gap visible so the eventual reviewer would know why the action cannot be assessed.

Status

The current page explicitly reports that no approval has been requested, granted, or denied. This is more precise than a generic pending status. It means the packet has not entered a live decision workflow.

A workflow draft can still display an approval gate in its activation checklist. The builder and the approvals page should be read together: one identifies the gate, and the other renders the information that would support a decision. Neither unlocks activation.

Do not infer status from the presence of a packet card. A generated preview is not pending review unless the product creates a persistent request, which the supplied implementation does not verify.

Escalation

Some proposed actions may need broader review because the route is sensitive, credentials are missing, evidence is incomplete, or the integration is not executable. In that case, keep the workflow blocked and share the draft, simulation result, route state, and relevant evidence with the appropriate product or security owner.

Do not escalate by copying secrets or inventing a decision. The goal is to resolve the underlying gap: clarify the action, verify the route, determine the required credential scope, or decide whether the capability should remain unavailable.

Because reviewer identities, deadlines, notifications, and escalation chains are not verified, this page does not define a formal approval-service procedure.

Limitations

Approval packets are simulation-derived and decisions are disabled. There is no evidence of signed approval persistence, reviewer assignment, notification delivery, escalation timers, or a live transition from approved to executable.

The surface remains useful for governance design. It shows where approval belongs and what information should accompany it. That value should not be overstated: a complete packet cannot compensate for an unavailable route, missing credential, blocked policy, or absent live activation path.

Keep every approval-related Workflow Agent record in preview status until a source verifies real decision capture and its effect on workflow state.

Packet contents

A useful packet should let a reviewer understand the proposed change without opening every builder panel. It can identify the workflow description, affected step, app, candidate route, connection state, approval reason, simulation outcome, and evidence references. Missing information should remain visible as a reason not to decide.

The packet should not include raw credentials or unrelated source data. If sample values are needed to explain the impact, use non-sensitive representations and label them as simulation inputs.

Relationship to activation

Approval is only one activation gate. A hypothetical approved decision would not make an unavailable route executable, repair an expired credential, or convert a generated connector from review-only to live. The builder must continue to evaluate route, simulation, connection, policy, and activation state independently.

The current product never reaches that hypothetical transition because reviewer actions are disabled. This makes the page suitable for packet design and governance review, not for authorizing work.

Changes requested during review

A request for changes would normally return the workflow to drafting with comments about the proposed action or evidence. The UI exposes the label but does not persist that result. To model the behavior today, revise the workflow description or steps directly, create a new simulation, and compare the updated packet preview. Do not claim that a reviewer comment thread or decision history was stored.

Sensitive action examples

Approval may be appropriate for external writes, changes to customer records, communication sent on behalf of a user, or actions using privileged credentials. These examples explain why a gate can exist; they do not assert that every named action or app is supported. The draft’s actual route and tool state remain authoritative.

Decision identity

A real approval system would need to identify the request, reviewer, decision, time, and decision scope. None of those persistable decision fields are verified on the Workflow Agent page. A packet preview can still show the proposed action and evidence, but it should not be assigned a reviewer or status that the system did not create.

Packet changes after a new simulation

When the draft or route changes, the approval packet should be treated as a new preview. Earlier evidence may no longer describe the proposed action. Compare the step, input, route, and simulation identifiers before using an older packet in review.

Approval-page sources do not establish packet versioning, so this comparison may be manual. Avoid saying that Workflow Agent invalidated or superseded the prior packet automatically.

Rejection and policy

A conceptual rejection and a policy block are different. Rejection would express a reviewer’s decision; policy block is a product control. The current page can show the latter through draft and simulation evidence but cannot persist the former. Do not label a policy-blocked action as rejected by a person.

Approval evidence quality

A packet should be narrow enough to support the exact decision. Include the relevant step and proposed impact rather than an entire unfiltered workflow. If the route is unavailable or credentials are missing, say so; the reviewer should not be asked to approve an action whose execution path cannot be assessed.

Handoff boundary

The packet can be shared for product, security, or process review, but the handoff remains outside a live approval service. Record any human feedback through the organization’s approved review channel and update the draft manually. Do not claim that the disabled controls captured that feedback.

Packet completeness check

A packet is useful when the proposed action, target app, route, connection status, reason for review, and simulation evidence are all visible. If the packet omits the affected record or expected impact, return to the draft rather than asking a reviewer to infer it.

No implied decision history

Disabled controls do not create a pending, approved, rejected, or changes-requested timeline. The page can display packet status and preview context, but it cannot serve as a decision ledger. Keep all records draft: true until persistable approval behavior is verified.

Reviewer context

The preview does not verify reviewer identity, assignment, or role permissions. A person viewing the packet should not be described as an authorized approver merely because the page is accessible. Organizational authorization remains outside the current Workflow Agent decision model.

Packet retention

No fixed retention or export behavior is established for approval previews. Important review material should be handled through an approved process, while sensitive evidence should be minimized. Never state that a packet remains available with the related draft indefinitely.

Approval reason clarity

The packet should state why review is needed in terms of the proposed action and impact. Generic “approval required” text is insufficient when the route, data change, or credential scope determines the risk.

Separate review from execution

Human agreement outside the product does not alter the disabled Workflow Agent controls. Update the draft and packet for clarity, but continue to represent the gate as unresolved in the product state.