Filing a signed document in the right folder, and never losing it
When a lease is signed, a Make scenario finds the signed PDF, files it in the right region and property folder in Google Drive, logs it in Airtable and tells the team in Slack, and if it cannot find the folder, it files the document in a holding folder and says so.
Where this applies
Property managers, landlords, agencies: any business that collects signed documents and files them by region, property or client.
- tiers of fallback, so nothing is lost
- 3
- wait for the signed file to land
- 10 s
The problem
A signed document has to end up where the team will look for it: the right region, the right property, named so it can be found. Left to a person, that is a download, a hunt through folders and a rename, and it is the kind of job that is done well on a good day and skipped on a busy one.
The automation has to cope with the real folder tree (organised by people, for people) and must never be the reason a signed document goes missing.
What we built
Triggered by the signature, not by a schedule
The e-signature tool posts to a custom webhook when a submission is signed, carrying the signed-document id, the participants, the region and the property address. Nothing polls.
Waiting for the file to land
The signed PDF reaches the shared Drive folder a moment after the webhook, so the scenario sleeps for ten seconds, then searches that folder for a file named after the signed-document id and only proceeds on an exact match.
Folders resolved by name, the way the team organises them
It finds the region folder by the submitted region, then a properties folder inside it, then the property folder whose name contains the submitted street line. Resolving by name rather than stored ids means it follows the way the team already works.
Three tiers, so nothing is lost
If the property folder is found, the PDF is filed there under a name built from the owner, street, state and signing date. If only the region is found, it goes into a 'Lease Submission' folder in that region; if not even that, into one at the top level. In every case a row is logged in Airtable (document id, name, file link, folder link, dates, email, region, address) and Slack says what happened, with a note when a folder was not found so a person can move the file.
Every step explains its own failure
Each Drive step has a handler that writes a described row (which branch, which step) to an error log, alerts Slack and rolls back, so a failure is a visible, explained event rather than a missing file.
The outcome
Built and wired end to end, with the webhook enabled and its queue empty.
It has not yet received a signed submission, so there is no run history to report; this page describes a design rather than a volume.
Where it stops
It has not yet processed a real submission. Folders are found by name, so a renamed folder, or two properties sharing a street line, would misfile; the fixed ten-second wait is a guess at when the signed file lands; the Airtable logging step has no handler of its own; and a failed submission is not retried automatically, so a replay is manual.
Built with
- Make.com
- Google Drive
- Airtable
- Slack
- Webhooks
Patterns used
- Tiered fallback
- Resolve by name
- Wait for the file
- Error log, alert, roll back
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