Pipelines — repeatable data preparation

Pipelines — repeatable data preparationCreate, bind, build, run, step through and schedule a pipeline; every step type and its options. A pipeline is an ordered recipe of steps — import, clean, reshape, mask, format, export, email — saved with the project and re-run on demand or on a schedule. It is bound to one dataset (a static pin or a named grid range); refreshing a static pin re-applies every pipeline bound to it. Every run is logged and every pipeline is its own Git-friendly JSON file.

Overview

A pipeline is an ordered recipe of steps — import, clean, reshape, mask, format, export, email — saved with the project and re-run on demand or on a schedule. It is bound to one dataset (a static pin or a named grid range); refreshing a static pin re-applies every pipeline bound to it. Every run is logged and every pipeline is its own Git-friendly JSON file.
Open the pipeline designer: Transform → Pipeline → Pipelines
Create a pipeline — short form: Transform → Pipeline → Pipelines → New pipeline → Bind… → Add step
1. Make sure the data is a static pin or a grid range. A preview (live) pin cannot be bound — convert it to a static pin from the grid's right-click menu first.
2. Transform → Pipeline → Pipelines opens the pipeline designer.
3. Click New pipeline.
4. Click Bind… and choose the dataset: a static pin, or a named grid range (Range name and Cells — use the current selection or pick on the sheet).
5. Click Add step, choose a group (Data in / out, Email, Rows, Columns, Values, Formatting) and a step, and configure it. Repeat; drag steps to reorder them; untick Enabled to keep a step but skip it.
6. Click Step through to preview the recipe one step at a time against an in-memory copy (Start walkthrough → Run next step or Run to end → Apply to data, or Reset).
7. Click Run to apply every enabled step, or Refresh & run to reload the bound pin from its source first. Undo last run restores the data exactly as it was before the last run.
8. To run it unattended, open File → File → Scheduler and tick the pipeline under Transform pipelines.

Transform → Pipelines

Opens the pipeline designer: a large window where an ordered recipe of steps is built, saved with the project and re-run on demand. The Add step menu has six groups — Data in / out (import, governed metrics, export, Run SQL, AI analysis), Email (read, send), Rows (sort, remove duplicates), Columns (merge, keep, drop), Values (value mapping, text cleanup, mask personal data, replace anomalies) and Formatting (clear, conditional, header row, borders). A pipeline is BOUND to one dataset — a static pin or a named grid range — and offers Run, Refresh & run (reload the source first, then run), Step through (walk the steps one at a time against an in-memory copy, with a preview, applying only when you say so), Undo last run, and Apply to another dataset with column remapping. Each run appends an immutable line to PIPELINES/pipeline-runs.log.jsonl and every pipeline is stored as its own git-friendly JSON file.
Requires: A pipeline must be bound before it can run.
Preview pin (live, paged query result) — Live pins cannot be bound or transformed; the designer lists them disabled with a conversion message.
Static pin (full query result loaded) — The normal target. A refresh of the pin automatically re-applies every pipeline bound to it.

Pipelines → Clear formatting step

The one step that changes how the data LOOKS rather than what it says. It removes conditional-format rules, cell styling (fill, font, borders), or both, over the region the pipeline is bound to, and can be narrowed to named columns — ticking none means every column in the region. It exists because reshaping data quietly invalidates the formatting sitting on it: a colour scale calibrated to last month's range, stoplight thresholds pointing at a column a later step merges away. Left behind, those colours keep describing numbers that are no longer there, which is worse than no formatting at all because it still looks authoritative. Put it FIRST when a recipe recalculates the values a scale was built for. The step reports zero rows affected on every run — that is correct, not a warning, because its work happens outside the table — and a step that is disabled, or skipped because an earlier step failed, clears nothing.
Requires: A bound pipeline. Column names refer to the DATASET, so a pinned region is matched by its query column names, not the sheet's C1/C2 headers.
Preview pin (live, paged query result) — Live pins cannot be bound, so this step never runs against one.
Static pin (full query result loaded) — The normal target. Clearing formatting never alters the pinned values themselves.

Pipeline designer controls

New pipeline — Create an empty recipe.
Bind… — Choose the dataset this pipeline runs against.
Rebind… — Point this pipeline at a different dataset.
Add step — Append a transformation to the recipe.
Enabled — Disabled steps are kept but skipped on run.
Run — Run every enabled step in order against the data as it is now.
Refresh & run — Reload the bound pinned dataset from its source first, then run the steps on the fresh rows.
Step through — Walk the steps one at a time with a live preview. Nothing is written until you apply.
Undo last run — Restore the bound data exactly as it was before the last run (pre-run snapshot).
Start walkthrough — Run the steps one at a time against an in-memory copy.
Run next step — Run the next step against the in-memory copy.
Run to end — Run every remaining step without applying.
Reset — Return to the table as it was before the walkthrough.
Apply to data — Write the staged result back to the bound data (single undoable run).

Step catalogue

Data in / out → Import data — Read rows into the pipeline from a file, a glob, an Azure / GCS / S3 object, or a database table or query — the same importer the Get Data tab uses, with the same typing, column and load options.
Data in / out → Governed metrics — Read governed metrics from the semantic layer — measures by dimensions, with saved filters, conditions and parameters — planned exactly as the dashboards plan them, under the publish gate and the data-access policy. The result becomes the pipeline's data; the run log names every definition it rests on and its certification.
Data in / out → Run SQL — Run a SQL script against the pipeline's own rows (registered as "input") or against a connection. Several statements run in order and the last one that returns rows becomes the data; the result can also be placed on a sheet.
Data in / out → Export data — Write the table AS IT IS AT THIS STEP to a file, a bucket, or a DuckDB / Postgres / BigQuery / Oracle table — the same exporter the Export tab uses. Several export steps each write their own point in the recipe.
Data in / out → AI analysis — Ask a model to summarise this step's data, a sheet range, a pinned block or the numbers behind a chart or pivot, and write the answer into a cell. Reuses the previous answer while the data is unchanged, so a scheduled recipe costs one call rather than one per run.
Email → Read email — Read a mailbox or a shared / group mailbox into the pipeline — through the Outlook desktop client on Windows, or IMAP anywhere. Filter by folder, date, sender, subject or unread, and the messages become the table the next steps work on.
Email → Send email — Email the table AS IT IS AT THIS STEP, optionally only when a condition holds — an aggregate over a threshold, a row count, any breaching row, or a new month appearing in the data. Nothing is sent while you step through the recipe; a run sends.
Rows → Sort rows — Order rows by one or more columns.
Rows → Remove duplicates — Drop repeated rows, keeping the first or last one.
Columns → Merge / concatenate columns — Join two or more columns into the first of them.
Columns → Split text into columns — Split one text column into several — on a delimiter such as a space or a comma, or at fixed positions. The parts go into new columns right after it; keep the original or replace it.
Columns → Keep only these columns — Everything not ticked is removed — the surviving columns keep the data's own order.
Columns → Drop columns — Remove the ticked columns; everything else stays.
Values → Value mapping (recode) — Rewrite values with a rule table (e.g. NY → New York).
Values → Text cleanup — Trim, change case, compress spaces, strip special characters.
Values → Mask personal data — Redact, partially hide, hash or replace names, e-mail addresses, account numbers and other personal data. One method per column; the project key stays out of the pipeline file.
Values → Replace anomalies — Line breaks, tabs, non-breaking and exotic spaces, zero-width characters, smart quotes and dashes, embedded HTML/script markup and Office export metadata, HTML entities — replaced with nothing, a space, decoded, or your own text.
Formatting → Clear formatting — Remove conditional formats and/or cell styling over the bound region — usually first, so later steps paint onto a clean sheet.
Formatting → Conditional formatting — Colour cells, change the font colour and add signs (↑ ✓ ✗) from the data itself — thresholds, colour scales, data bars and icon sets.
Formatting → Format header row — Style the header: fill, text colour, font, size, bold/italic, alignment and wrapping. Direct formatting, so it looks the same whatever the data does.
Formatting → Borders — Draw or remove borders — all, outside only, inside only or a single edge — on the header row, the data rows, or the whole region.

Steps in detail

The steps a recipe can use
Add step opens a menu of six groups. DATA IN / OUT: Import data, Export data, Run SQL and AI analysis — the steps that reach outside the pipeline. EMAIL: Read email (a mailbox or a shared mailbox, through the Outlook desktop client on Windows or IMAP anywhere, becomes the table) and Send email (mails the table as it is at that step, optionally only when a condition holds; nothing is sent while you step through the recipe). ROWS: Sort rows, Remove duplicates.
COLUMNS: Merge / concatenate columns, Keep only these columns, Drop columns. VALUES: Value mapping (recode), Text cleanup, Mask personal data and Replace anomalies — the last two are the Privacy and Data quality tools run on every refresh. FORMATTING: Clear formatting, Conditional formatting, Format header row and Borders. AI ANALYSIS asks a model to summarise this step's data, a sheet range, a pinned block or the numbers behind a chart or pivot, writes the answer into a cell, and reuses the previous answer while the data is unchanged, so a scheduled recipe costs one call rather than one per run.
It also answers ROW BY ROW: point "Write the answer at" at a column of cells instead of a single cell and the step asks the question once per input row — first row of the data into the first cell, second into the second — which is how a column of comments becomes a column of classifications.
Formatting steps — header styling and borders
Add step → Formatting holds four steps. "Clear formatting" wipes conditional rules and/or cell styling over the bound region — put it first when a recipe should paint onto a clean sheet. "Conditional formatting" installs live rules that re-evaluate against the data on every refresh. The two DIRECT formatting steps do not read the data at all, so they look the same whatever the numbers do. "Format header row" styles the header: fill, text colour, font, size, bold/italic/underline, horizontal and vertical alignment, and wrapping; fields left on "(unchanged)" are not written, so this step can add a fill without disturbing a font another step set.
"Borders" draws or removes borders — all, outside only, inside only, or a single edge (top/bottom/left/right) — on the HEADER row, the DATA rows, or the WHOLE region; the edges are computed against whichever target you picked, so "outside" on the header boxes the header while "outside" on the whole region boxes the table, and adding the step twice combines them. Both steps can be limited to some columns instead of the whole region. WHICH ROW IS THE HEADER comes from the binding, not the step: a pinned region uses its header overlay row (a pin set to "no headers" has none, and the step says so rather than styling your first record), and a grid range uses its first row.
Re-running a recipe writes the same styles again rather than stacking anything, so a nightly refresh leaves the sheet exactly as the first run did — but note that direct styling stays on the sheet if you later delete the step, so pair it with "Clear formatting" when you want a reset.
Dropping and keeping columns
Two pipeline steps under Add step → Columns narrow the data. "Drop columns" removes the ticked columns and leaves everything else; "Keep only these columns" removes everything EXCEPT the ticked ones. Both editors list the bound dataset's columns as checkboxes with Select all / Clear / Invert. Surviving columns keep the DATA's own left-to-right order, not the order you ticked them, and every later step in the recipe sees only the survivors — so a sort or a merge referring to a removed column fails with a clear message, which is usually the signal that the steps are in the wrong order.
Error handling differs on purpose: dropping a column that is not in the data is reported as a note rather than a failure (the same recipe often runs against datasets with slightly different shapes), while keeping ONLY columns that do not exist fails loudly and lists the columns that are actually available, because it would otherwise wipe the table — that is nearly always a typo or a renamed column. Dropping every column is refused outright. What happens on write-back depends on the binding: a PINNED region genuinely narrows (its column list and width shrink, exactly as a refresh returning fewer columns would), while a GRID RANGE has the removed columns' cells blanked in place — a pipeline never inserts or deletes sheet columns.
Undo last run restores the original width either way.
Data in / out — import and export steps
Add step → Data in / out holds the five steps that reach OUTSIDE the pipeline — Import data, Governed metrics, Export data, Run SQL and AI analysis (Governed metrics, Run SQL and AI analysis are described separately) — and the Email group beside it holds Read email and Send email. "Import data" reads rows in through the SAME importer the Get Data tab uses, so it supports everything that dialog does — a local file or a glob, an Azure / GCS / S3 object, a database table or a query — with the same typing, column and load options, and it gains anything added there later.
Its MODE decides what the rows do: "replace" makes the step the pipeline's SOURCE (the usual first step of a recipe that pulls its own data rather than reading the bound region), while "append" unions the fetched rows onto the table that is already there, which is how several files or partitions become one dataset mid-recipe. The import's own destination setting is ignored — a pipeline step's destination is the pipeline table, never a sheet and cell.
"Export data" writes the table AS IT IS AT THIS STEP through the same exporter the Export tab uses: a file, a bucket object, or a DuckDB / PostgreSQL / BigQuery / Oracle table. Because each export step captures the rows at ITS OWN position, several of them in one recipe write several different snapshots — raw on arrival, cleaned after the transforms — rather than all writing the final result. "Skip when the table is empty" is ON by default and is the setting that matters most in a scheduled recipe: without it, an upstream filter that matched nothing quietly overwrites yesterday's good file with a header row and nothing else.
The export is also the one step that does not change the data, so it can sit anywhere without affecting what the steps after it see.
AI analysis — one answer, or one per row
Add step → Data in / out → "AI analysis" puts a question to a model and writes what it says into cells. It reads one of four things — this step's data, a range on a sheet, a static pinned block, or the numbers behind a chart or pivot — and it has no tools: it cannot run queries, read anything it was not handed, or change anything else, which is what makes it safe to leave in a scheduled recipe. WHERE THE ANSWER GOES ALSO DECIDES WHAT IT DOES. Point "Write the answer at" at a SINGLE CELL and the step reads the whole source and writes one answer about it — the summary, optionally spread one line per cell downwards, with a provenance line naming the model, the time and how many rows it saw.
Point it at a COLUMN OF CELLS (drag on the sheet, or type C5R2:C5R101) and the step answers ONCE PER INPUT ROW: row 1 of the data answers into the first cell, row 2 into the second, and so on, which is how a column of comments becomes a column of sentiments or a column of product names becomes a column of tidied ones. Each row is put to the model with its FIRST column as the subject and its other columns as context, so the question can still say "…given the amount".
The block you pick is a CEILING as well as a destination: the step answers at most as many rows as the block has cells and never writes past it, so a source that grew overnight cannot scribble down somebody's sheet. A row the model did not answer is left EMPTY rather than untouched — a stale answer beside today's data would read as an answer about today. Per-row work is batched, several rows to a model call rather than one call each, and the answers are matched back BY ROW NUMBER, so a batch that comes back out of order or one line short never shifts answers onto the wrong rows.
Two settings matter more than the rest in an unattended recipe: "Recompute" left on "Only when the data changed" reuses the previous answers while the data behind them is unchanged, which is what keeps an hourly pipeline to one set of calls rather than 24; and "Rows to send" caps what actually leaves the machine — if it is lower than the height of your answer block, the rows past it stay empty and the dialog says so. The data policy applies exactly as it does to Ask Greg: the same masking and the same limits, and a policy level that forbids sending individual rows refuses a per-row step outright rather than inventing one verdict per row from summary figures.
Run SQL — SQL as a pipeline step
Add step → Data in / out → "Run SQL" runs a SQL script in the middle of a recipe. The editor takes a CONNECTION (leave it on the local engine, or pick any configured database), the SQL itself, and an optional placement. SEVERAL STATEMENTS are allowed, separated by semicolons: they run in order and the LAST one that returns rows becomes the pipeline's table, so a step can create a temporary table, insert into it and then select from it — the setup statements do their work and the final SELECT is the answer.
The editor shows how many statements it found, so a stray semicolon inside a string is visible before you run anything (quoted text, dollar-quoted blocks and -- or /* */ comments are not treated as separators). WHAT THE SQL CAN READ: on the LOCAL engine the pipeline's current table is registered before the script runs, under the name shown in the editor (input by default), so a step refines what the steps before it produced — SELECT region, SUM(amount) FROM input GROUP BY region.
That is the whole point of it being a step rather than a separate saved query: it sees the data mid-recipe. Against a REMOTE connection the query runs on that server, which knows nothing about your rows, so input does not exist there and the editor says so rather than letting the SQL fail with a confusing "table not found" — a remote step is a fresh source, and the usual shape is to import or query remotely first and reshape locally afterwards. SAVED QUERIES: pick any saved SQL query or saved VISUAL query and its SQL is COPIED into the step.
Copied, not linked, on purpose — a pipeline whose behaviour changed because somebody edited a saved query somewhere else would be impossible to reason about; the step remembers which query it came from so it can say so, and you re-pick it to take a newer version. PLACING THE RESULT: ticking the placement section additionally drops the result on a sheet at a chosen top-left cell — the pipeline's own tab or any other, picked with the "Pick on sheet" button — either as a static PIN (one refreshable block that later steps and other features can bind to) or as plain CELLS you can edit afterwards, with or without a header row.
Placement is off until you choose it, so a SQL step used purely to reshape data for the steps after it leaves nothing behind on the document. A placed block carries no SQL of its own, so "Refresh Data" skips it; re-running the pipeline is what updates it, and re-running writes over the same block rather than stacking a second copy beside it.
Alert rules — AI explanation and "Check with AI"
An alert rule can add a SHORT AI EXPLANATION to the message it sends: switch on "Add a short AI explanation to the message" in the rule's AI explanation section, set the length and, optionally, the model. When the rule fires, the alert's data and the condition's result go to the model under the data policy, and the paragraph it writes goes into the message where the body template has {{aiExplanation}} — or at the top when it has none — followed by a line saying it was AI-generated and by which model.
Three things hold whatever the model says. It NEVER DECIDES whether the alert fires: the condition and the suppression rules do, exactly as before, and the model is told their verdict. Its figures are CHECKED against the alert's data, and a paragraph with a figure the data does not hold is not sent — the message carries the condition's own sentence instead, and the run log says why. And a model that is down, refused or slow never stops the alert: the message goes out without the paragraph.
Insight watches (anomaly, change, forecast) are where this reads best: the watch states what happened, the paragraph says it in a sentence a recipient can act on. CHECK WITH AI evaluates the rule on the current data without sending anything or remembering anything, and shows the verdict — fires, held back by suppression, not met but within 10% of the threshold, or not met — with an AI explanation of why, how close it is and which values decide it.
Use it to try a threshold before trusting it to a schedule.
Governed metrics — reading the semantic layer in a pipeline
The GOVERNED METRICS step (Data in / out group) reads measures from the semantic layer into a pipeline instead of hand-written SQL, so a scheduled recipe gets the SAME figure the dashboards and Ask Greg show — "Revenue" means the certified definition, not whatever a copied query happened to sum. Choose the measures and dimensions the way a metric widget does; type a dimension as urn:analytics:dimension:order_date/Month to break a hierarchy down by one level.
Saved filters add the semantic layer's own named restrictions; CONDITIONS add fixed ones (dimension, operator, values), and their values may use ${param} so a nightly run can ask for "last month" or a channel held in a project parameter. PARAMETERS set the semantic layer's parameter objects; an empty value means the parameter's default, and true/false, numbers and [JSON lists] are read as such. Sort, row limit (at most 10,000) and the result mode — replace the pipeline's data, or append by column name — complete the request.
The query goes through POST /api/semantic/query, so it is planned exactly as the dashboards plan it, under the publish gate (reports read the published version) and the data-access policy (a user who may only see web orders gets web orders here too), and it is audited as semantic.query. Three things make it safe to put behind a schedule. A result CUT AT THE ROW LIMIT fails the step by default, because a governed total missing rows looks right and is wrong; untick "Fail when the result is cut" only when a top-N is what you want.
"Run only on certified definitions" refuses figures that rest on anything uncertified and names it — use it for recipes that feed regulated or board reporting. And the run log names every definition the figures rest on with its certification and a short version hash, e.g. Revenue [certified #3fa9c2d1], so a number in last month's workbook can be traced to the exact definition that produced it. Preview runs the real query for 20 rows and shows the SQL, the planner's notes and the provenance.
The result can also be placed on a sheet at a cell, and "Write the column names as the first row" puts a header above the bound range. Ask Greg does not propose this step yet; for a metric question in chat it uses query_metrics.
Masking as a pipeline step
Add "Mask personal data" from the Values group of the Add step menu in the pipeline designer. It edits with the same dialog as the one-shot tool, offering the pipeline binding's columns, and saves a rule per column into the step. Three differences from the ribbon tool are worth knowing. It always masks IN PLACE — a pipeline cannot write masked copies into new columns, both because added columns would invalidate every later step's column references and because a scheduled run that left the originals beside the masked copies would ship the personal data it was added to remove.
It arrives EMPTY rather than pre-scanned, so a step you added and never opened cannot silently mask whatever a scan liked the look of; open it and the scan runs. And it is STRICTER about missing columns than most steps here: if a column named in the rules is not in the table when the pipeline runs, the step fails and the run stops. That is on purpose — the alternative is a renamed source column turning into a scheduled export that quietly stopped masking it, which is the failure you would least like to find out about from outside.
The step also refuses to run at all if no project key is available, rather than falling back to a fixed one: masking under a known constant looks exactly like masking and protects nothing. A rename earlier in the pipeline carries the rule with it, so a mask rule survives a column that a previous step renamed.
Dimensions (as references) — The same list as text, comma-separated. Add /Level to break a hierarchy down by one level, e.g. urn:analytics:dimension:order_date/Month.
Conditions — Fixed restrictions on dimensions. Values may use ${param}, so a scheduled run can ask for "last month".
Values — Comma-separated. "between" takes two.
Parameters — Values for the semantic layer's parameters. Empty uses the parameter's default. ${param} is resolved first; true/false, numbers and [JSON lists] are read as such.
Preview — Runs the real query (first 20 rows) and shows the SQL, the planner's notes and every definition the figures rest on.
Analyse — What the model is shown. Nothing else about the project is sent.
Range — Type it, or click the target and drag on the sheet.
Chart or pivot — The step reads the numbers the object plots, not the picture.
What should it say? — Plain English. The more specific the question, the more useful the summary.
Write the answer at — One cell for one answer about everything; a column of cells for one answer per row. Type it, or click the target and drag on the sheet.
Recompute — Reusing an unchanged answer keeps a scheduled recipe cheap and stops the cell being reworded every run.
If it fails — A model endpoint having a bad ten minutes should not throw away a transform that worked.
Model — Which of the models configured under Ask Greg → Providers answers this step. Pinning one keeps a scheduled recipe on the same model: changing the default would otherwise change every unpinned step's answer and re-run all of them, because the saved answer is tied to the model that wrote it.
Rows to send — What actually leaves this machine. The data policy may send fewer, and the answer says how many it saw. Figures describing every row are always sent, whatever this is set to.
Placed as — One cell keeps it tidy; one line per row suits bullet points.
Add a line saying where it came from — The model, the time, and how much data it saw. On by default: machine-written prose sitting in a spreadsheet with nothing to say where it came from is what gets quoted in a meeting six months later.
New pipeline — Create an empty recipe.
Bind… — Choose the dataset this pipeline runs against.
Rebind… — Point this pipeline at a different dataset.
Run — Run every enabled step in order against the data as it is now.
Refresh & run — Reload the bound pinned dataset from its source first, then run the steps on the fresh rows.
Step through — Walk the steps one at a time with a live preview. Nothing is written until you apply.
Undo last run — Restore the bound data exactly as it was before the last run (pre-run snapshot).
Add step — Append a transformation to the recipe.
Enabled — Disabled steps are kept but skipped on run.
Start walkthrough — Run the steps one at a time against an in-memory copy.
Run next step — Run the next step against the in-memory copy.
Run to end — Run every remaining step without applying.
Reset — Return to the table as it was before the walkthrough.
Apply to data — Write the staged result back to the bound data (single undoable run).
Range name — Named ranges survive row/column insertion, so the pipeline keeps pointing at the same data.
Cells — Pick the cells on the sheet, or use whatever is selected. The name is given to these cells.
Invert — Tick everything that is NOT currently ticked.
Delimiter — A space, a comma, " - " … several characters are fine.
Cut after character — e.g. 3, 7 — splits "ABCDEFGHI" into ABC, DEFG, HI.
New column names — Comma-separated, in order. Left empty, they are named <column>_1, <column>_2, …
recipe changed since last run — The step list changed since the last run (hash mismatch in the run log) — results shown may not reflect the current recipe.
Where it runs — The local engine can see the pipeline's own rows. A connection runs the query on that server instead.
Row limit — A ceiling on what the query may bring back, so a careless script cannot pull a million rows into the pipeline.
Start from a saved query — Any query from the project library — written SQL or one built visually; both carry SQL.
Name for the pipeline's rows — The table name the steps before this one are exposed under. Default: input.
Sheet — Where the rows land. The pipeline's own tab is used when nothing is chosen.
Start cell — Top-left corner of the block. Pick it on the sheet — a dragged selection collapses to its top-left cell.
Land it as — A pin is one refreshable block other features can bind to. Plain cells are values you can edit afterwards, and nothing keeps them in step with the query.
Mailbox — Leave empty for the profile's own mailbox. Name a shared or group mailbox to read that instead.
Body contains — Searching message bodies is much slower than searching headers on most servers.
Maximum messages — A mailbox can hold tens of thousands. This ceiling is what keeps a step from hanging.
Message body — Bodies are fetched one message at a time, so leaving this off is much faster.
Write column names in the first row — Puts receivedAt, from, subject and the rest in row 1, with the messages from row 2 down. Applies to a grid range; a pinned region keeps the header setting it was created with. Turning this on shifts every row down by one and overwrites whatever is in row 1 now.
Mark the messages as read — Off by default. This is the only setting here that changes the mailbox, it happens on a preview as well as a run, and nothing undoes it.
Save attachments to — A folder on the machine running the app. Leave empty to list attachment names only.
Columns to watch — Comma-separated. Leave empty to watch the whole table.
Only when it changes — On by default. Without it, an alert on a 15-minute schedule sends every 15 minutes for as long as the condition stays true - and by the second day nobody reads any of them.
Cooldown (minutes) — Never send twice within this many minutes. 0 turns it off.
To — Comma-separated. A distribution list or a group mailbox counts as one address.
Rows in {{table}} — How many rows the inline table shows before it says how many more there were.
Do not send when the table is empty — On by default. This is what stops a filter that matched nothing from mailing everybody a header row.

Glossary terms on this page

ATX Institute on LinkedIn

This site needs JavaScript for the full experience. Every page above is reachable without it.