A monthly sign-off loop that files its own evidence
Three Make scenarios email each active staff member a pre-filled compliance form on the first of the month, file the signed PDF as evidence when it comes back, and chase anyone still unsigned on the fifth.
Where this applies
Any business that has staff or partners attest to a statement on a schedule and must keep the evidence.
- scenarios: send, collect, remind
- 3
- acknowledgements captured per signature
- 5
- places the evidence is filed
- 2
The problem
A business that has staff attest to a statement every month has three jobs: get the form to everyone, get the evidence filed where an auditor can find it, and chase the people who have not signed. Done by hand, the third is the one that gets forgotten.
The form also has to know who is signing, because a signature that cannot be matched to a person is not evidence.
What we built
Status as the state machine
Each person's record moves from Sent to Received when they sign, or to Reminder Sent when they are chased, so nobody is reminded twice in a cycle. The send is selected by a next-send date equal to today and advances the date to the first of next month, which makes it idempotent for the day and self-advancing.
The link carries the identity
The form link is pre-filled with the person's name, email and Airtable record id, and states the deadline in the email: end of the fifth.
Evidence in two places
When the form is submitted, a webhook creates a response record with the five acknowledgement checkboxes, downloads the submission as a PDF, uploads it to a Drive archive named by signer, month and year, and attaches both the PDF and the signature image to the Airtable record. The attachments go through Airtable's content API with raw HTTP because the native module cannot upload them. The signer then receives a confirmation email with their signed copy.
Chase only the unsigned
On the fifth, the reminder scenario selects active people whose status is still Sent, sends an amber overdue email with the same pre-filled link, marks them Reminder Sent and stamps the date.
A heartbeat for every run
Every scenario writes a success or error row to a heartbeat table and posts a summary to an automation-health channel. Each risky step has its own handler: a failed send to one person alerts and carries on with the rest, while a step that creates state rolls back.
The outcome
The three scenarios close the loop (send, collect, remind), with the evidence filed twice and every run leaving a heartbeat.
The run history is short: a handful of runs since September, including the collector's successful runs on 2 to 4 September.
This page describes the design rather than a volume.
Where it stops
The run history is short. A scheduled run that fails before it starts, for instance on an expired email authorisation, raises none of the in-flow alerts, so scheduled sends want a check from outside the scenario. The collector matches the signer by name text rather than by the record id the link carries, and the send is capped at ten people per run.
Built with
- Make.com
- Airtable
- Jotform
- Gmail
- Google Drive
- Slack
Patterns used
- Status as state machine
- Identity in the link
- Dual evidence storage
- Heartbeat table
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Have something shaped like this?
If any part of the above resembles a problem you are living with, a short call is the fastest way to find out whether it is the same problem underneath.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no