Design a Rewst approval gate before a service-desk write

The design uses Rewst's documented workflow builder and Classic organization model, retrieved October 7, 2026.^[5]^[6] It is not a tested Rewst export or a deployed Crate. We did not access a Rewst workspace, PSA or Microsoft tenant. UI labels and access depend on the reader's deployed experience; do not substitute a newly announced agent feature for this documented builder path.

Who owns the request and the boundary

An automation builder prepares the workflow; the service manager owns the approval standard; a tech lead reviews integrations and a technician checks whether the proposed note is useful. The dry-run deliverable is a decision record containing the request, validated organization context, proposed note, approval status and duplicate decision. It creates no PSA note, user, license or customer message.

Use an existing authorized Rewst workspace with access to the workflow builder. Have its administrator confirm contractual entitlement and approved execution allowance. The cited builder documentation establishes the implementation surface, not a price or unlimited usage.^[5] No purchase, trial conversion or additional integration is needed to review this design. If a required feature is missing, record the gap rather than buying access.

Specify a fictional work unit

The fictional request is REQUEST-0042 for child organization LAB-A, PSA company COMPANY-A and ticket T-1042. Its source note says: "Printer comparison is pending. Service manager to review by October 16. Replacement is not approved." The proposal is a new internal note retaining those facts, not a status change or client notification.

The expected dry-run result is one record: request REQUEST-0042, validated LAB-A/COMPANY-A/T-1042 mapping, exact proposed note, revision 1, status pending, no write executed. After an authorized approval simulation, the result becomes approved-proposal-only. An approval must never be displayed as proof that a write happened.

Define the logical idempotency key as organization ID plus ticket ID plus request ID plus action type. Store the approved revision or proposal fingerprint with it. This is a design requirement, not a claim that Rewst automatically deduplicates arbitrary workflows. Choose a persistence mechanism and concurrency control that the administrator can demonstrate; if none is available, stop at dry-run.

Prepare organization and permission checks

Rewst Classic distinguishes the MSP parent organization and customer child organizations. Organization variables can inherit parent values, and child overrides can change them.^[6] Record the selected child, integration instance, PSA company mapping and approver route explicitly. A populated organization variable is not evidence that its mapping is correct.

Do not accept a submitted organization ID as authority. Compare the signed-in requester's authorized organization, selected execution context and returned PSA company/ticket ownership. An inherited parent approver address must not silently approve a customer action. For the first fixture run, use static records instead of customer integrations.

If an approved read-only check later needs an integration, inspect its actual permissions and scope first. Rewst's Microsoft Cloud bundle documents selectable permissions and customer-to-child-organization mapping, with compatibility consequences when changing its suggested permissions.^[8] Do not install that bundle for this PSA-only exercise, grant broad rights for convenience or assume suggested permissions are least privilege for your task. Have the relevant integration owner prove the narrow reads and keep writes absent.

Build the dry-run path

Step 1: In a new, clearly labeled draft workflow, keep operational triggers disabled. Use a manually supplied fixture with dry-run fixed true. Required inputs are request ID, allowed child organization, ticket ID, requester reference, source note and proposal revision. Missing values route to an exception result, not defaults.

Step 2: Add validation tasks before proposal construction. Check allowlisted organization and company mapping, requester authority, ticket ownership and allowed note type. Route any mismatch to blocked with a reason. Use no-operation fixture actions and explicit outputs where appropriate; the builder documentation describes testing with static data and no-op actions.^[5]

Step 3: Look up the logical idempotency key. A completed matching request returns already-handled. A pending matching request returns the existing pending record. A changed proposal requires a new revision and renewed approval. For simultaneous runs, reserve the key atomically in the chosen mechanism; a lookup followed by an unprotected insert is insufficient. Do not invent a Jinja expression or storage action for a mechanism you have not checked.

Step 4: Prepare an approval record with exact proposal, organization, ticket, revision, requester, expiry and approver. In the fixture, use explicit approve, deny, expire and unauthorized-approver responses. The final record must bind approval to the same proposal revision. A free-text "yes" copied from a ticket is not the authentication check.

Step 5: Branch to approved-proposal-only, denied, expired or blocked. Approval does not enable a write in this version. A later implementation needs a verified authenticated approval mechanism and separate write-stage review. Do not import the onboarding Crate as a harmless starting template: Rewst documents that it provisions users immediately by default and its approval option is disabled by default.^[7]

Step 6: Use Run and Run Test only after inspecting every task. Rewst's test command initiates an execution and offers an organization selection; it is not a guarantee of simulated external actions.^[5] Select the fixture organization, inspect execution results and keep the workflow undeployed against operational triggers. A dry-run flag is effective only when the actual write tasks are unreachable or absent.

Require failures to stay visible

Fixture case	Required result	Proposed pass threshold
Valid request, pending decision	One pending proposal, zero external writes	Exactly one record
Authorized approval	Approved-proposal-only for same revision	Zero PSA writes
Denial or expiry	Terminal denied or expired; no later continuation	Zero writes and zero queued write tasks
Wrong child/company/ticket	Blocked with mismatch reason	Zero cross-customer reads or writes
Repeated request	Existing result reused	Zero duplicate approval requests
Simultaneous duplicate	One reservation succeeds; other observes it	One logical proposal
Changed revision after approval	Old approval invalidated	New authenticated decision required
Lookup or approval failure	Visible exception, manual queue item	Zero false success records

These tests are not reported as passed. Require every case before considering a write stage. In that later stage, revalidate identity, proposal revision and ticket ownership immediately before writing; handle uncertain external outcomes by reading the exact target before retrying. Never count a timeout as proof that nothing changed.

Pause, rollback and count the remaining work

The dry-run fallback is the normal manually reviewed note process. The pause owner disables the workflow's permitted trigger and reviews in-flight executions; disabling a trigger alone may not stop work already running. For a later PSA-note write, retain the external note ID and before/after evidence. Correct or remove a mistaken note only through the PSA's authorized process. This guide offers no universal undo transaction.

Review mappings and approvers at customer onboarding, approver changes and integration reauthorization. Check pending approvals daily during an authorized pilot and exercise the duplicate/failure suite after workflow edits. Do not enable all current and future customers for convenience.

Compare manual preparation with review, approvals, exceptions and maintenance. Count setup and distinct work units, not executions. Separate elapsed delay from active effort; approval remains human work.

The working discipline

Automate before you hire

Prove organization context, authenticated approvals and atomic duplicate control with a no-write fixture before any write stage. Count approval, exceptions and upkeep, not workflow executions, as remaining work.

Review the sequence →

Worksheet / Usable takeaway

Rewst approval and duplicate-control worksheet

Boundary: [workflow reference / deployed experience / existing entitlement / dry-run status / allowed organization / excluded writes / execution allowance].
Ownership: [builder / service manager / integration reviewer / authenticated approver / pause owner / manual fallback].
Work unit: [request ID / child org / company mapping / ticket ID / requester authority / note type / source reference].
Proposal: [exact text / revision / fingerprint method / expected outcome / expiry / no-write proof].
Isolation: [selected execution org / integration instance / parent inheritance review / mapping evidence / ticket ownership / denied identity].
Duplicate control: [logical key / persistence mechanism / atomic reservation proof / pending behavior / completed behavior / revision rule].
Approval: [authentication mechanism / approved proposal revision / decision / expiry / evidence / production mechanism still outstanding].
Tests: [case / expected record count and write count / actual / evidence / pass, fail or not run / correction].
Future write gate: [separate authority / least-privilege review / read-back method / uncertain-outcome handling / rollback target / approval].
Maintenance and value: [mapping review trigger / pending queue owner / baseline / review and exception effort / setup / net observed effort / continue, revise or stop].

Open the worksheet: Rewst approval and duplicate-control worksheet Download (Markdown)