Slack and MySQL: Approval-Audited Database Write Template

A webhook-triggered workflow that pauses for a human approval announced in Slack, then writes the approved change to MySQL and records an audit row, the approve-then-persist pattern.

What It Builds

A Webhook trigger receives a change request from your system, a Human node pauses the run and posts a notification to Slack so a reviewer can approve or reject, and only after approval does a Connector node on MySQL apply the change. A second MySQL step then inserts an audit row capturing who approved, what changed, and when, so every persisted write has a paper trail. Because a rejection halts the run in Spojit, nothing is written unless a person signs off.

The Prompt

Paste this into Miraxa and it builds the workflow, connecting the tools for you:

Build a workflow with a Webhook trigger that receives a record change request. Add a Human approval node that posts a notification to the #approvals channel in Slack and waits for a reviewer to approve. When approved, use the MySQL connector to write the change to the target table with execute-query, then add a second MySQL step that inserts an audit row recording the approver, the requested change, and the approval time. If rejected, the run should stop without writing anything.

Connectors Used

• Webhook trigger - external systems POST the change request to the workflow URL, verified by a Slack-scheme or Custom signing connection.
• Human node - pauses for approval, posts the notification, and gates the database write behind a person.
• Slack - announces the pending approval in a channel with send-message so reviewers see it where they already work.
• MySQL - applies the approved change with execute-query or update-rows, then logs the audit row with insert-rows.

Customize It

Swap #approvals for the channel your reviewers watch, point the MySQL steps at your real table and columns, and set a timeout on the Human node (blank means it waits indefinitely, treated as a reject when it lapses). To require more than one sign-off, tell Miraxa to add extra approval slots, and to widen the audit row, name the extra fields you want stored such as the requesting user or a request id from {{ input }}.

Tips

• Keep the MySQL steps in Direct mode so the write is deterministic and costs no AI credits, since you know the exact table and query.
• Put the audit insert-rows step immediately after the write so the two persist together, and include the approvalId from the Human node output in the audit row.
• Use a parameterized statement in execute-query rather than concatenating values from {{ input }}, so request data never reshapes the SQL.

Related

• Want the step-by-step? See How to Create a Multi-Step Approval Workflow.
• Using Human Approval Nodes explains slots, timeouts, and Slack notifications.
• How to Build a Webhook-Triggered Order Processing Workflow covers the same Webhook-to-write pattern.