Reporting and operations
Report automation: send a weekly Google Sheets summary by email
Every Monday, someone opens the same spreadsheet, filters last week's rows, calculates the same totals, writes an email, and sends it to the team. Reporting automation connects that routine into a scheduled workflow. The aim is not another dashboard to maintain: it is a short, dependable summary that arrives where people already work and points them to the decisions that need attention.
Key takeaways
Define the reporting question before choosing the nodes.
A schedule needs a timezone and an exact reporting window.
Keep calculations deterministic; send once per period.
Define one reporting period and a few useful metrics. Schedule a workflow to read the relevant Google Sheets rows, validate and aggregate them, create a concise email, and record its send result. Use a stable period identifier so a retry does not send the same report twice.
- Schedule
- Read rows
- Validate and total
- Compose summary
- Send and record
1. Choose one recurring decision, not every available metric
Start with the question the recipient asks each week. A sales manager may want to know which quotes need a response. An operations owner may need the number of completed jobs and a list of overdue work. A finance team may want a reconciliation report. Those are different reports even if the information lives in one spreadsheet.
For a first version, choose three to five metrics and one action list. Give each metric a definition: what counts, which date determines inclusion, and which rows are excluded. A report called weekly revenue is ambiguous until you decide whether it means invoices issued, payments received, or orders booked.
Agree on the recipient and destination. A private team summary should go to an approved internal list, not every address found in the source sheet. Put detailed records behind an appropriately restricted link and keep the email focused on the information its readers actually need.
- Question: what should the reader decide?
- Period: which records belong in this report?
- Metrics: which definitions will remain consistent?
- Action list: which items need an owner and a next step?
2. Give the sheet a small, stable data contract
A predictable table is easier to automate than a presentation spreadsheet with merged headings, subtotal rows, and notes mixed into the data. Keep one record per row and separate source records from calculated presentation tabs. Use a persistent record ID rather than the current row number, because sorting the sheet changes row positions.
The n8n Google Sheets node supports Get Row(s) and row updates. In a simple workflow, select the spreadsheet and sheet explicitly, read the source records, and then apply your reporting-window filter. Check the result contains the expected columns before calculating anything; a renamed heading should produce a clear exception, not a blank report.
Normalise dates and statuses at the boundary. If one row says complete and another says Completed, define whether both mean the same thing. Store numeric amounts as numbers, and keep currency separate. Do not add USD and PKR into a single amount unless a documented conversion rule supplies the rate and date.
| Field | Example purpose | Rule |
|---|---|---|
| record_id | Identify one job | Required and unique |
| completed_at | Select completed work | Timestamp with an agreed timezone |
| status | Include eligible records | Use a defined status list |
| amount and currency | Calculate a subtotal | Number plus currency code |
| owner and due_at | Build the action list | Keep missing owners visible |
3. Make the schedule and reporting window explicit
Use a Schedule Trigger for the agreed day and time. n8n uses the workflow timezone when configured, otherwise the instance timezone; its current documentation also requires saving and publishing the workflow for the schedule to run. Set the workflow timezone deliberately rather than relying on the machine's default.
For example, a Monday 09:00 report in Asia/Karachi can cover the previous Monday at 00:00 through the current Monday at 00:00, excluding the ending boundary. That is a half-open window: include the starting instant, exclude the ending instant. A record exactly at this Monday's midnight belongs in the next report, not both.
Calculate the window from the intended reporting date, not blindly from the moment a retry happens. If Monday's report is recovered on Tuesday, it should still describe the same week. Store the window start, window end, and timezone in the run record and display the period in the email subject.
Decide what happens after a missed schedule or late data. A scheduled trigger alone is not a complete recovery policy. The owner can run a named historical period, or the workflow can use a separate controlled catch-up process. A corrected report should be marked as a revision, not silently overwrite the history of the first send.
4. Build and reconcile a small example before sending
Worked example: a service team has five job records. Three eligible completed jobs have amounts of USD 120, USD 180 and USD 200. One job remains open and one completed job falls outside the period. The report shows three completed jobs and a completed-work subtotal of USD 500.
Keep a traceable list of the three included IDs and the reasons the other two were excluded. Reconcile the output against those rows manually during the pilot. If a duplicate ID appears twice, decide whether the source must be fixed or one approved latest version should be selected before aggregating.
Create the email from a stable layout: reporting period, key figures, exceptions, and a link to the underlying sheet. A short plain-language summary is usually more useful than a large attachment that nobody opens. If an AI model drafts commentary, give it only the verified totals and exception list; the calculation itself should not depend on generated text.
| Email section | Example content |
|---|---|
| Period | Previous calendar week in the configured timezone |
| Completed work | 3 jobs; USD 500 subtotal |
| Action needed | 1 open job; show its responsible owner |
| Data notes | 1 out-of-period job excluded |
| Details | Restricted source-sheet link |
5. Record the send result and handle uncertain outcomes
Give each report a key such as weekly-operations plus the period start and revision. Reserve that key in a durable run log before sending. A second execution should recognise an existing sent report or an in-progress send instead of treating every run as a new email.
Google's Gmail API supports sending directly or sending a saved draft. Save the returned message identifier when available. An accepted send request is evidence that the service accepted the action; it is not proof that every recipient received or read the email.
The awkward case is a timeout after a send may have succeeded. Mark that run as uncertain and reconcile it with the provider's records or the sent mailbox before retrying. Do not automatically resend just because the workflow failed to save its final status. This distinction prevents duplicate Monday summaries.
Define a separate failure notification for the workflow owner. It should state the period, failed stage, and recovery action without dumping private source rows into a public channel. A data error should not produce a success email with guessed figures.
6. Pilot the report and keep it easy to change
Run the first version with synthetic records and a test inbox. Test an empty period, a missing column, an invalid amount, a boundary timestamp, a duplicate record, and a rerun of an already-sent period. Then compare the report with the team's existing manual process before switching the normal recipients on.
An empty valid period and a failed data read are not the same outcome. The first can send a clearly labelled no-activity report if that is useful; the second should take the failure route. Document this choice so the team does not confuse silence with a healthy system.
Keep recipients, timezone, metric definitions, and subject format in a small configuration area. Name a reporting owner who can update those settings and test a change. Our reporting automation service can help connect the source, calculations, email, and recovery path; the weekly reporting guide covers broader scoping, while our data-check article focuses on the checks that keep totals trustworthy.
Your ready-to-use checklist
0 of 10 checked
Make the next step clear.
Copy this weekly report automation brief
Free templateSources and notes
Sources checked on October 19, 2026.
- n8n: Schedule Trigger
Supports fixed schedules, workflow/instance timezone behaviour, and the requirement to publish the scheduled workflow.
- n8n: Google Sheets node
Lists supported row-reading and row-writing operations used in a Sheets-based workflow.
- Google Gmail: send email
Documents direct message sending and sending an existing draft; successful submission is not a read receipt.
