Run a Make dispatch only after approval

Outcome and scope

Build a dispatch workflow that acts only on an approved request. Slack carries the review notification, while a restricted management table records the actual approval. A casual emoji reaction is not the approval mechanism in this design. Keep the approver, approved version and dispatch result together so a changed request cannot inherit an obsolete decision.

Approval covers destination, attachments and action type as well as message text. Decide which changes create a new version, and show the request identifier and summary in the Slack notification.

Prepare the fields and destination

Prepare these fields: Request ID, content version, destination, reviewer, approved version, approval time, dispatch state and result ID. Keep source values separate from a reviewer’s confirmed values, and do not reuse an existing column for a different meaning. Create the first record with practice identifiers in a destination whose read and edit access matches the intended staff roles. Inspect the saved result from that role before using live information.

Hidden columns are not access controls. If the chosen management table cannot enforce the required departmental approval boundary, use an authenticated approval application instead.

Build the workflow in order

Create explicit draft, review, approved, dispatched and exception states. Freeze a destination and content version before sending the review request to Slack. Link to a management surface with controlled editing access, not a public sheet where any recipient could alter the approval columns.

The execution scenario must check that the current content version equals the approved version, in addition to checking an approved flag. A destination or message change sends the request back to review. Keep approval and dispatch responsibilities separate where the organization requires it, and configure the table permissions accordingly.

Recheck the request identifier immediately before dispatch and search for an existing result for that version. Save the returned result ID after sending. A second attempt should stop at the existing result. A spreadsheet alone is not a strong concurrency lock, so higher-risk dispatches need appropriate serialization or a store with enforceable uniqueness.

Work through a small example

Approve version one of a practice request, then change its destination to create version two. Execution should stop while the approved version remains one. After an authorized reviewer approves version two, dispatch it once. Retrieve the same row again and check that the existing result prevents a second send.

Handle changes during operation

Preserve cancellation history. Cancelling before dispatch differs from requesting reversal afterward, and an external action may not be reversible. Do not describe a sent item as unsent simply by changing a local status.

Estimate cost and usage

Separate the cost of reviewing pending requests from notification, dispatch and result storage. Choose a polling interval that matches the required response delay rather than rereading every unapproved request constantly. Include management-table editor seats and the plan required for access control; Make subscription cost alone does not describe the whole approval operation.

Investigate failures

A status-write failure after a successful send leaves an ambiguous request. Reconcile the external result before choosing to resend. Compare destination, request version and returned delivery identifier. Route uncertainty to an exception state instead of automatically retrying an action whose first outcome is unknown.

Review before release

Before release, test a normal record, one missing a required value, a repeated identifier and an edited record. Use request id to trace the saved result back to the source. The acceptance condition is: Dispatch the approved version once; changed requests return to review. Record the expected result before testing, compare it with the actual saved state, and resolve unexplained differences before increasing the scope.

• Choose an internal approval workflow
• Filters and routers in Make
• Prevent duplicate processing in Make