Job emails into the Excel register, once each
A Make scenario watches a shared Outlook inbox for job emails, reads the Excel register to see what is already logged and adds a row only for what is new. It ran 34 times in the month to 21 October 2026 without an error.
Where this applies
Trades, estimators and any small team whose work arrives by email and is tracked in a shared Excel workbook.
- runs in a month, no errors
- 34
- modules, no data store
- 8
- row per job, however often it is emailed
- 1
The problem
Many trade businesses take work by email: a request to quote, a job from a builder, a set of plans. The team tracks it in a spreadsheet, and someone has to copy each email into it. Miss one and a job is never priced; copy one twice and two people chase it.
Appending a row per email is the easy part. The hard part is knowing whether the row is already there, because the same job is often emailed more than once.
What we built
A filtered watch
The scenario polls the shared inbox, and a filter lets through only the emails that match what a job email looks like, so other mail never reaches the register.
Read the register first
Before it writes anything, the scenario lists the workbook's existing rows and aggregates them into one text: the set of entries already logged. That read has a retry handler, so a moment's failure to reach the workbook does not lose the email.
Only what is new
The email's items are iterated and a filter drops any already present in that set. Only the remainder becomes rows, so a job emailed twice is logged once.
The register is the memory
Eight modules, one trigger and no data store: the workbook itself records what has been logged, so staff can see and correct it in Excel, and the scenario respects their corrections on the next run.
The outcome
34 runs between 18 September and 21 October 2026, all successful, using 160 credits.
One run on 25 September did not complete first time and went through on Make's automatic retry.
Built in June 2026 and switched on.
Where it stops
The duplicate check compares what the email carries with what the register holds, so a job emailed again with different details is logged as a new row. The whole register is read on every run, which is fine at this size and slows as the workbook grows. Mail that the filter does not recognise is ignored, so a job sent in an unexpected format is not logged.
Built with
- Make.com
- Microsoft 365 Email (Outlook)
- Microsoft 365 Excel
Patterns used
- Read before write
- Text aggregate as a key set
- Retry on the read
- Spreadsheet as the memory
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