A variation raised on the job becomes a branded PDF in the client's inbox
When a variation is raised on a job in monday.com, a Make scenario gathers its lines, fills a branded Google Docs template, saves it as a PDF, emails it to the client for approval and logs on the job that it went. The client's response is handled by separate scenarios that are not described here.
Where this applies
Builders, joiners, fit-out firms and any business that prices changes to a job and needs the client's agreement in writing.
- PDF per variation, from the business's template
- 1
- updates written to the job on every send
- 2
- modules in the scenario
- ~25
The problem
On a building job, a variation (a change to the agreed scope and price) has to reach the client in writing, with every line and the new total, and the client has to agree before the work goes ahead. By hand, that is a document typed from the job notes, saved, attached and sent, and the job record rarely says that it went.
The weak point is the document more than the email. A variation with several lines has to come out as one tidy, consistent page every time, from data that sits as separate entries on the job.
What we built
Started from the job
The scenario watches the job board for events and reads the item that changed, so raising the variation where the job is managed is what sets it going. Nobody has to open another tool.
Collect the lines, then render
One route iterates the variation's lines and, through a four-way router, stores them as variables. The next route reads them back, so the template receives the whole variation at once rather than a line at a time, and a multi-line variation becomes one document.
A template the business owns
The document is created from a Google Docs template and downloaded as a PDF. The wording, layout and branding live in the template, so the business can change them without touching the scenario.
Sent and logged
A second four-way router sends the PDF to the client by Gmail, and each of its routes writes two updates back to the job, so anyone opening the job can see the variation went out.
Approval as a separate event
The client's response and the approval arrive later, so they are handled as events of their own by companion scenarios rather than by a scenario that waits. Those companions are not described on this page.
The outcome
Built between November 2025 and March 2026 as one scenario of about 25 modules.
It is switched off and Make holds no run history for it, so this page describes a design rather than a volume.
Where it stops
This page covers sending the variation, not agreeing it: the scenarios that record the client's response and mark the variation approved are not described, so no claim is made that the approval loop is complete. The scenario is switched off. Its routes are fixed, so a change to how variations are structured on the job means a change to the scenario.
Built with
- Make.com
- monday.com
- Google Docs
- Gmail
Patterns used
- Template to PDF
- Collect lines, then render
- Write back to the job
- Approval as its own event
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