Anticode Open builder

Approval workflow app: show the request-and-approve flow, and route real requests to Slack

Approval workflows look simple on a whiteboard and get complicated the moment real requests arrive: thresholds, deputies, rejections that need a reason, and the question of who can see what. Anticode can prototype the whole flow on one device with sample requests, which is the right place to settle the rules. It can't move a request from one person's screen to another's, but a published request form can post each real request into Slack today.

Updated · By the Anticode team

Write the rules before the screens

Most approval tools fail because the rules were never written down, so people route around them. Settle these with the people involved before building anything.

What can be requested
Purchases, leave, discounts for a client, content for publication, access to a system. Each type may need different fields and approvers.
Who approves
A named person, a role ("the requester's manager") or a group where any one member can approve.
Thresholds
Spend under 500 needs the manager; over 500 also needs finance; over 5,000 also the director. Write them as a table everyone can see.
Order
Approvers in sequence, or in parallel where all must agree.
Rejections and changes
A reason is required. Can the requester edit and resubmit, or must they start again?
Absence
A deputy when the approver is away, or an escalation after a set number of working days.
Record
Who approved, when and on what version of the request. This is the part auditors ask for.

Prototype the flow

Describe the request types and rules, then ask for each role's view so you can switch between them on one screen: "An approval workflow app prototype for purchase requests at a design agency. Requesters fill in item, supplier, amount, cost code and reason. Under 500 the line manager approves; above it, finance approves after the manager. A role switcher at the top: requester, manager, finance. Each role sees an inbox of what's waiting for them, with approve, reject with reason, and ask for changes. A timeline on every request showing each step. Twenty sample requests in different states, labelled demo data. Everything saved in this browser."

Run a short session with a manager and someone from finance, playing out real cases from last month. The arguments that start ("does a renewal count as a new purchase?") are exactly the rules you were missing. Adjust the prototype in words, and keep each version in history so you can compare.

Real requests today: a form into Slack

You don't have to wait for a full system to start capturing requests properly. Publish the request form as part of the app. Its contact form sends name, email and a message, with any extra fields (amount, cost code, supplier) added to the message, through Anticode's form pipeline. Each request reaches you by email and in your Anticode inbox, and the Slack connector can post it into a channel such as #purchase-requests.

  1. The requester fills in the form on the published app and sends it.
  2. The request appears in the Slack channel shortly after.
  3. The approver replies in the thread with a decision; finance does the same for larger amounts.
  4. Someone marks the final outcome with an agreed emoji or a closing reply.

It's crude, but the conversation and the record sit in one place, and it costs little to run. A Google Sheets or Airtable connector can keep a parallel log of every request for monthly review. Each submission is sent once, without retries, so check the channel occasionally against your Anticode inbox.

What the sandbox can't do

  • No hand-off between people. The approver's inbox in the prototype is sample data; a request made on one phone never reaches another.
  • No sign-in or identity. The app can't tell who is approving, so it can't enforce who may approve what.
  • No reminders or escalation. Nothing runs in the background to chase a late approver.
  • No attachments. Forms have no file uploads, so ask for a link to a quote or invoice.
  • No integration with accounting or HR systems.

For a real multi-step system, look at your existing tools first: many accounting, HR and helpdesk products have approvals built in. A custom one could start from the Next.js export, whose roles, sign-in and audit log are the right foundations, with the request tables and routing written by a developer. See also the internal tool builder page.

Questions people ask

Can an approval workflow app built with Anticode send requests to approvers?

Not between users of the app. A published request form can send each request to you and on to Slack, where approvers reply.

Can approvers click approve in Slack?

Not through Anticode. The connector posts the request; the decision is a reply or reaction in the channel.

Is the Slack route good enough for an audit?

It gives a timestamped record, but anyone in the channel can edit their replies. If auditors need a fixed record, use a system with an approval log.