Module 1 · The pipeline mindset
This is not a spreadsheet
Concept
You already know how to work with tables — you've been doing it in a spreadsheet for years. That experience is useful, but it also teaches a habit you need to unlearn here: in a spreadsheet, you operate on cells. You type a formula into one cell, then drag it down, then drag it across, then do it again next month when the new export lands. Every cell is its own tiny decision.
BeAutomating works on tables, not cells. A step doesn't say "put this value in row 47, column C" — it says "compute this expression for every row" or "keep only the rows matching this condition." You describe the transformation once, declaratively, and it applies to the whole set at once — this row, the next 10,000 rows, and every row in a file you haven't even imported yet.
That's the shift this whole course is built around: from cell-based and manual, to set-based and reusable.
In a spreadsheet you type =A2*1.1 and drag it down 10,000 rows — you manage every cell.
In BeAutomating you add one Calculated Column step, price * 1.1. It applies to every row at once — and to next month's data automatically. No dragging, no $A$1, no paste.
Do it
- Open BeAutomating and click + Add Step. Don't add anything yet — just look at the categories in the picker: Clean, Reshape, Calculate, Summarize, Arrange, Visualize, Advanced.
- Read each category name as a verb applied to a whole table, not a cell — "Clean the table," "Reshape the table," "Calculate a column across the table." That's the vocabulary you'll use for the rest of this course.
- Close the picker without adding a step. You're just getting your bearings.
Check
In a spreadsheet, what happens to your dragged formula when 500 new rows land below it next month?
Nothing, automatically — the formula only exists in the cells you dragged it into. You have to notice the new rows and drag it again, by hand, every time. A BeAutomating step has no such edge: it's defined against the table as a whole, so when you run the same recipe on next month's file, every row — old shape, new size — gets the same transformation with zero extra work.
Module 1 · The pipeline mindset
Recipe, step, run
Concept
Three words carry the whole model, and you'll see them everywhere in this course:
Table. Rows and columns — the same shape whether it came from a CSV, an Excel export, or the output of a previous step. Everything in BeAutomating starts as a table and ends as a table.
Step. One transformation — a Filter, a Calculated Column, a Group & Summarize — that takes a table in and produces a table out. Steps chain: the output of one is the input of the next.
Recipe. An ordered list of steps, saved together. That's the whole automation: table → step → step → step → table. Build it once against this month's file, and it's ready to run again, unchanged, against next month's.
In the app, each step has its own ▶ Re-run control — click it and that step executes against its input table right there, so you see the result immediately, not after some separate "compile" or "submit." That immediacy is deliberate: you build a recipe by watching each step land correctly before you add the next one.
One more thing worth knowing before you import anything: BeAutomating runs this entirely on your machine. There's no upload, no server round-trip, no cloud step in between — your data stays on your Mac from the moment you drop the file in.
Do it
- Open BeAutomating and locate three things on screen: the current table preview (rows + columns), the + Add Step button, and — once a step exists — its ▶ re-run control.
- Say the model out loud once, in order: "table, in through a step, table, out." That's the entire mental model — everything else in this course is which step to reach for.
Check
Which of these changes your whole table, not just one cell: typing a value into a spreadsheet cell, or adding a Calculated Column step?
The Calculated Column step. Typing into a spreadsheet cell changes exactly that cell — and only that cell, until you manually copy it elsewhere. A Calculated Column step is defined against the table, so it produces a value for every row the moment you run it, and for every row in any table you run the recipe on afterward.
Module 1 · The pipeline mindset
Import your first sheet
Concept
Every recipe starts with a table, and the table starts with an import. BeAutomating reads CSV, TSV, Excel (.xlsx / .xls), and JSON files directly — drop one onto the app, or click to browse, and it's parsed into a table preview in seconds. There's no format conversion step, no "save as CSV first" ritual: bring the file you already have.
Because everything runs locally, importing a file doesn't send it anywhere. You're handing the app a copy to read into memory on your own machine — the source file on disk is untouched, and nothing leaves your Mac.
Pick something real for this lesson if you can: an AR aging export, a monthly transaction list, a customer list — anything with real column headers you'll recognize. You'll build your first recipe against it in the next lesson.
Do it
- Open BeAutomating's data view and find the drop zone — it reads "Drop your data file here" with "CSV, Excel (.xlsx), or JSON" underneath, and "or click to browse."
- Drag a CSV or Excel file onto it (or click to browse and pick one). Anything with a header row and a few hundred rows works well for practice.
- Confirm the table preview shows your real column headers across the top, and that the row count roughly matches what you expect from the source file.
Check
You imported a file and one column that should be numbers — like "amount" — shows up looking like text. Is that a problem yet?
Not yet. Import's only job is to get your file into a table you can see and work with; it doesn't try to guess and fix your data types for you. A text-looking number column is completely normal at this stage — you'll fix it deliberately with a Clean step (Module 2) once you know what you're building. For now, just confirm the shape is right: the columns and row count match the source file.
Module 1 · The pipeline mindset
Your first 1-step recipe
Concept
You've imported a table and you understand the model: table in, step, table out. Time to actually build one — the smallest possible recipe, a single step, so the mechanics click before Module 2 loads you up with the full step catalog.
You'll reach for Filter, from the Arrange category: pick a column, set a condition, and the table narrows to only the rows that match. It's the same instinct as a spreadsheet's AutoFilter — except this time it's not a view trick applied on top of your data, it's a step you can see, re-run, and hand to next month's file unchanged.
Do it
- With your imported table from Lesson 1.3 open, click + Add Step → Arrange → Filter.
- Pick a column that means something to you — amount, status, date, whatever your file has — and set one condition (e.g. amount greater than 0, or status equals "Overdue").
- Click the step's ▶ to run it, and watch the row count in the preview drop from your full table down to just the matching rows.
Check
How many rows did you start with, and how many after the filter ran? If the row count didn't change at all, what's the first thing to check?
If the count is identical before and after, the most common cause is a mismatch between the condition and the column's actual type or values — for instance comparing a text-typed number column with a numeric condition, or a typo in a status string like "overdue" vs. "Overdue." Open the step, re-check the exact column and condition, and re-run. That mismatch-diagnosis habit is exactly what Module 2's Clean lesson (2.1) exists to prevent before it happens.
Module 2 · The transform steps
Clean
Concept
Every step here acts on the whole column or table — you are not editing cells. You describe the transformation once; the engine applies it to all rows, and to any new data you run the recipe on.
Module 1 got you a table on screen and one working step. Module 2 is the full toolbox: seven categories, each a different verb applied to the whole table. We start with Clean, because messy tables break every step downstream of them — a Filter comparing text to a number, a Join that misses rows because of stray whitespace, a chart with three slightly different spellings of the same category.
Four Clean steps, four jobs:
Fix Data Types — tells the engine "this column is actually numbers / dates / booleans," so every value in it is reinterpreted at once, not row by row.
Rename / Select Columns — renames headers and drops the columns you don't need, across the whole table in one step.
Deduplicate — removes repeated rows (by whichever columns you choose to match on) from the entire table.
Fill Missing — replaces blank cells with a default, a previous value, or a computed one, for every empty cell that matches, everywhere in the column.
In a spreadsheet you'd select the "amount" column, run Find & Replace or a helper column, then paste-special the results back over the original — and repeat it by hand on next month's export.
In BeAutomating a single Fix Data Types step, applied once, converts every value in the column — this run, and the next one, automatically.
Do it
- Open a table where a numeric-looking column — like "amount" or "quantity" — is actually stored as text (you'll often see it: numbers left-aligned instead of right-aligned in the preview, or a Filter step that silently matches nothing).
- Click + Add Step → Clean → Fix Data Types. Select the column and set its type to Number.
- Run the step and check the preview: the whole column is now right-aligned as numbers, not just the row you were looking at.
Check
You ran Fix Data Types on one column. Next month's file has the exact same problem in the exact same column. What do you have to redo?
Nothing. The step is defined against the column, not against this month's specific cells — so when you re-run the saved recipe on next month's import, the same conversion happens automatically, before you even look at the data. That's the entire point of a Clean step over a spreadsheet fix: you diagnose the problem once and it stays fixed for every future run.
Module 2 · The transform steps
Reshape
Concept
Clean fixes what's wrong inside a table. Reshape changes the table's shape — combining tables, restructuring rows into columns (or back), and splitting or joining text values. Six steps:
Union / Stack — stacks two or more tables with matching columns into one longer table.
Join / Lookup — matches rows between two tables on a shared key, the way VLOOKUP tries to, except it works both ways and doesn't break when rows get reordered.
Pivot — turns unique row values into new columns, summarizing as it goes.
Unpivot (Wide→Long) — the reverse: turns columns into rows, useful for wide exports (one column per month) you need in a normal analyzable shape.
Text Split — breaks one column into several, on a delimiter or pattern.
Text Combine — merges several columns into one.
In a spreadsheet, twelve monthly exports means twelve tabs, and combining them means copy-pasting each one, by hand, into a master tab — then doing it again next January. A Union / Stack step describes "combine these tables" once; point it at twelve files, or thirteen, or a whole folder next year, and it stacks them the same way every time.
Do it
- Import twelve monthly CSV files that share the same columns (e.g. twelve months of transactions, or twelve monthly sales exports).
- Click + Add Step → Reshape → Union / Stack, and add all twelve tables as inputs.
- Run the step and confirm the row count equals the sum of all twelve files' rows — one continuous table, no manual copy-paste, no thirteenth tab to remember next year.
Check
Next January, file #13 lands. What has to change in your recipe?
Point the Union step at the thirteenth file (or, if you're importing a whole folder, nothing at all). You're not re-copying eleven other tabs by hand to make room for it — the step already describes "stack whatever tables are given to it," so adding one more input is the only change, and every other step downstream re-runs unchanged.
Module 2 · The transform steps
Calculate
Concept
This is the lesson where the "not a spreadsheet" reframe stops being an idea and becomes something you can see. A Calculated Column is not a formula pasted into one cell and dragged down — it's a column expression, evaluated for every row automatically, forever, for as long as the step exists in the recipe.
Four Calculate steps:
Calculated Column — write an expression once (price * 1.1, revenue - cost); it becomes a new column, computed for every row.
If-Then (Case When) — conditional logic per row: "if status is Overdue, label it High Risk," evaluated for the whole column at once.
Date Extract — pulls a part out of a date column (year, month, weekday) for every row.
Window / Running — running totals, rankings, or comparisons to prior rows, computed across the table's row order.
In a spreadsheet: you type =B2*1.1 into C2, drag the fill handle down 10,000 rows, and the formula lives in 10,000 separate cells. Insert a row at the top and every reference shifts; import next month's file and you drag it again.
In BeAutomating: a Calculated Column step holds one expression — price * 1.1 — that isn't stored per-row at all. It's evaluated fresh, for every row, every time the step runs. There's nothing to drag, nothing to re-paste, and no cell reference to break when rows shift.
Do it
- On a table with a
pricecolumn, click + Add Step → Calculate → Calculated Column. - Name the new column
price_with_taxand enter the expressionprice * 1.1. - Run the step. Confirm every row — not just the first one — now has a filled-in
price_with_taxvalue. - Now import (or paste in) a handful of extra rows above the ones you started with, and re-run the recipe from the top. Confirm the new rows also got
price_with_taxfilled in — you defined the column once, and it applied itself to rows that didn't even exist yet when you wrote the expression.
Check
You add 200 new rows to your source file and re-run the same recipe. Do you need to touch the Calculated Column step at all?
No. The step doesn't say "compute this for rows 1–500" — it says "compute price * 1.1 for whatever rows are in the table." Row 501 through 700 get the same expression applied the moment the step runs, with zero edits to the step itself. That's the whole difference from a dragged-down spreadsheet formula, made concrete.
Module 2 · The transform steps
Summarize
Concept
Where Calculate adds detail per row, Summarize collapses many rows into fewer, meaningful ones. Two steps carry this category, and the second is the one finance teams tend to light up about:
Group & Summarize — pick one or more columns to group by (e.g. customer), and an aggregation to apply within each group (sum, count, average, min, max) on another column (e.g. amount). One group per unique value, computed across every matching row.
Aging Buckets — the classic AR-aging move: given a due date (or an age in days), it sorts every row into buckets like Current, 1–30, 31–60, 61–90, 90+ — the exact structure of an accounts-receivable aging report, built with one step instead of a maze of nested IFs.
In a spreadsheet, an AR aging report is usually a pivot table wired to a wall of nested IF formulas computing days-overdue per row, rebuilt (or at least re-pointed) every time the invoice list refreshes.
In BeAutomating, Group & Summarize then Aging Buckets is two steps, described once, that re-run identically on next week's invoice export.
Do it
- On an invoices table with
customer,amount, anddue_datecolumns, click + Add Step → Summarize → Group & Summarize. Group bycustomer, aggregateamountwith Sum. Run it and confirm you now have one row per customer, with their total outstanding amount. - On the original (ungrouped) invoices table, add a second Summarize step: Aging Buckets, pointed at
due_date. Run it and confirm every invoice row now carries a bucket label — Current, 1–30, 31–60, and so on.
Check
You have 3,000 invoice rows. After Group & Summarize by customer, how many rows should you expect?
One row per unique customer — not 3,000. Group & Summarize collapses every row that shares a group key into a single summarized row, so the count you see tells you whether it worked: if you still see 3,000 rows, the grouping didn't take, or the aggregation was applied to the wrong column.
Module 2 · The transform steps
Arrange
Concept
You already met half of this category in Lesson 1.4 — Filter was your first-ever step. Arrange is the category for narrowing and ordering a table without changing what's inside each row. Two steps:
Filter — keeps only the rows matching a condition (amount > 0, status = "Overdue").
Sort / Top N — orders the table by one or more columns, ascending or descending, and optionally keeps only the first N rows — the declarative version of a spreadsheet's Sort + manually deleting everything past row 10.
In a spreadsheet, "top 10 overdue invoices by amount" means AutoFilter to overdue, Sort descending by amount, then manually select and delete every row past 10 — a view built by hand, gone the moment you touch the data again.
In BeAutomating, that's a Filter step (status = Overdue) chained into a Sort / Top N step (sort by amount descending, limit 10) — two described steps that reproduce the exact same top 10 on any invoice file you run them against.
Do it
- On your invoices table, click + Add Step → Arrange → Filter. Set the condition to
status equals Overdue. Run it. - Chain a second step: + Add Step → Arrange → Sort / Top N. Sort by
amount, descending, and set the limit to 10. Run it. - Confirm the final table is exactly 10 rows — the largest overdue invoices, in order — and that both steps still show in the recipe above it, re-runnable independently.
Check
Why does the order matter — Filter then Sort/Top N, not Sort/Top N then Filter?
Sort / Top N first would pick the 10 largest invoices overall, then filter that small set down to whichever of those 10 happen to be overdue — you could end up with 3 rows, or 0. Filter first narrows the table to only overdue invoices, then Sort / Top N picks the top 10 within that overdue set — the actual answer to "top 10 overdue invoices." Step order changes the result, just like it would in a spreadsheet workflow done in the wrong sequence.
Module 2 · The transform steps
Visualize
Concept
Visualize is where a table stops being rows and columns and becomes something you can read at a glance. Two steps:
Chart — turns a table (usually the output of a Group & Summarize) into a bar, line, or pie chart, picking the columns for axes and series.
Statistics — computes summary numbers (count, sum, mean, min, max, standard deviation) across a column, so you can sanity-check a result without eyeballing thousands of rows.
Like every other step in this course, a Chart or Statistics step is attached to the recipe, not to this one result — re-run the recipe on next month's data and the chart redraws itself against the new numbers, with no rebuilding.
Do it
- Using the per-customer summary table from Lesson 2.4 (customer + summed amount), click + Add Step → Visualize → Chart. Set customer as the category axis and summed amount as the value.
- Run it and confirm you get a bar per customer, tallest-to-shortest telling you your biggest outstanding balances at a glance.
- Add a second step, Visualize → Statistics, on the same summed-amount column. Run it and read the total, average, and max across all customers.
Check
Your Chart step's bars all look nearly identical in height, but Statistics shows a huge range between min and max. What does that mismatch tell you?
Something's off in how the chart is grouped or scaled — most often, the Chart step is pointed at the wrong column, or it's summarizing pre-grouped data a second time and flattening the real spread. Statistics gives you the ground truth for a column's actual range; when the chart doesn't visibly reflect that range, trust the numbers and go back to check the Chart step's configuration before trusting the picture.
Module 2 · The transform steps
Advanced
Concept
Six categories cover almost everything you'll need. For the remaining edge cases — a transformation too specific for any picker, or a query you already know how to write — there's one escape hatch: Custom SQL.
Custom SQL lets you type a SQL query directly against your table and use its result as the step's output. It looks like a break from everything else in this module — actual code, not a picker — but it isn't a break from the model. It's still one operation, described once, that runs against the whole table and re-runs identically on whatever table you point the recipe at next. The declarative promise of every other step in Module 2 holds here too: you're not looping over rows by hand, you're describing a result set once.
Reach for Custom SQL when a transformation genuinely doesn't fit the picker — a multi-table calculation, a window function BeAutomating's UI doesn't expose yet, a query you already have written from another tool. It is a power-user tool, not a default: if a named step (Filter, Join, Group & Summarize) already says what you mean, prefer it — it stays readable to you, and to anyone else who opens the recipe, six months from now.
Do it
- On your invoices table, click + Add Step → Advanced → Custom SQL.
- Write a query that reproduces something you could have built with named steps, so you can compare results — for example:
SELECT customer, SUM(amount) AS total FROM table WHERE status = 'Overdue' GROUP BY customer ORDER BY total DESC. - Run it and compare the output to what a Filter → Group & Summarize → Sort chain would have produced. Confirm they match — same rows, same order.
Check
Your Custom SQL step and an equivalent Filter → Group & Summarize → Sort chain produce the same table. Which should you keep in the saved recipe, and why?
Prefer the named-step chain when the two are truly equivalent. It's not about correctness — SQL runs the same table-wide operation the picker steps do — it's about who has to read the recipe later. Three labeled steps tell their own story at a glance; one SQL block requires reading and mentally parsing a query to know what it does. Save Custom SQL for the cases the picker genuinely can't express.
Module 3 · Data in & out
Importing
Concept
You imported one CSV back in Lesson 1.3, just to get a table on screen. Now that you know the full step catalog, it's worth going back and looking at import itself more closely — because real finance data rarely shows up as one clean file.
BeAutomating reads three shapes of input, all landing in the same drop zone: CSV / TSV (the universal export format almost every system spits out), Excel (.xlsx / .xls, including files with multiple tabs — you pick which sheet becomes the table), and paste (copy a range straight out of Excel or Google Sheets and paste it into the drop zone; it's parsed into a table exactly like a file would be, no intermediate save-as-CSV step).
And it handles more than one file at once: drop a folder, or select multiple files in the browse dialog, and BeAutomating imports each one as its own table. That matters the moment you have "twelve monthly exports" instead of one — you saw the payoff of that in Lesson 2.2's Union / Stack step, but the setup for it starts here, at import.
In a spreadsheet, twelve files means opening twelve workbooks, or importing them one at a time into twelve tabs, then remembering which tab is which before you can even start combining them.
In BeAutomating, you drop all twelve at once. Each becomes its own table, ready to feed into a Union / Stack, a Join, or whatever the recipe needs — no manual tab bookkeeping.
Do it
- Open BeAutomating's data view and find an Excel workbook that has more than one tab (if you don't have one handy, any multi-sheet
.xlsxworks). Drop it on the import zone and confirm you're prompted to choose which sheet becomes the table. - Now select two or three files at once — either drag them together onto the drop zone, or use "click to browse" and multi-select. Confirm each file lands as its own separate table, not merged into one.
- Finally, open a spreadsheet app, select a small range of cells, copy it, and paste directly into BeAutomating's drop zone. Confirm it parses into a table the same way a file import would.
Check
You drop three CSV files onto the import zone at once. Do you get one merged table or three separate ones?
Three separate ones. Import's job is only to turn each file into a table you can see — it never guesses that you want them combined. If you do want them combined, that's a deliberate choice you make afterward with a Reshape step: Union / Stack for "same columns, stack the rows," or Join / Lookup for "match rows between them on a key." Import and combine are two different decisions, kept separate on purpose.
Module 3 · Data in & out
Cleaning a messy export
Concept
Module 2 introduced each Clean step in isolation. Real exports rarely need just one — they need a short chain, because a single messy file usually breaks in three or four ways at once. This lesson walks through one worked example, start to finish, so you see the chain building up rather than just the finished recipe.
Picture a typical "export from the old system" invoice file. It has three separate problems layered on top of each other:
Bad types — the amount column looks like "$1,204.50", text with a dollar sign and a comma baked in, not a number the engine can sum or compare.
Duplicates — the export tool re-sent a batch of rows, so a chunk of invoice numbers appear twice, identical in every column.
Blanks — some customer cells are empty because the old system dropped the value on legacy records.
Fixing all three by hand, every month, in a spreadsheet is exactly the kind of repeated manual work this course exists to eliminate. Here, it's three Clean steps, chained once:
Step 1 — Fix Data Types on amount: strip it to a real number. Now "$1,204.50" becomes 1204.50, sortable, summable, comparable — for every row in the column at once.
Step 2 — Deduplicate on invoice_number: the re-sent batch collapses back down to one row per invoice, keeping the first occurrence.
Step 3 — Fill Missing on customer: blank cells get a placeholder like "Unknown" (or a computed fallback), so a downstream Group & Summarize by customer doesn't silently drop rows with no group key.
Notice the order: types before dedupe before fill. Deduplicate needs to compare real values, so cleaning up type noise first avoids a false "these look different" mismatch; fixing blanks last means you're not overwriting a value type-casting might have flagged.
Do it
- Import (or paste) a deliberately messy invoices file —
amountas text with a currency symbol, a handful of duplicatedinvoice_numberrows, and a few blankcustomercells. If you don't have one handy, build a small one on purpose: it's a good way to see each step's effect clearly. - Click + Add Step → Clean → Fix Data Types. Set
amountto Number. Run it, and confirm the column is now right-aligned and the currency symbol/commas are gone. - Chain a second step: Clean → Deduplicate, matching on
invoice_number. Run it and confirm the row count drops by exactly the number of duplicate rows you seeded. - Chain a third step: Clean → Fill Missing on
customer, with a default value like"Unknown". Run it and confirm no cell in that column is blank anymore. - Scroll back through the recipe and look at all three steps stacked together — that's the whole "clean a messy export" pattern, reusable on next month's equally messy file with zero changes.
Check
Why run Fix Data Types before Deduplicate instead of after?
Deduplicate compares row values to decide what counts as "the same row." If amount is still text at that point, formatting noise — a stray space, a different number of decimal places written out as text — can make two rows that are really duplicates look different, so some duplicates slip through uncaught. Fixing types first means Deduplicate is comparing clean, consistent values, which is exactly why the worked example puts it first in the chain.
Module 3 · Data in & out
Outputs
Concept
Every lesson so far has ended the moment the table looked right on screen. That's the middle of the loop, not the end of it — a recipe only earns its keep once its result leaves the app and lands somewhere useful: a chart someone can screenshot into a deck, a set of statistics that answers "is this number normal," or a clean sheet handed back to a colleague who doesn't use BeAutomating at all.
You already met the two Visualize steps in Lesson 2.6:
Chart — bar, line, or pie, built from a table (usually a Group & Summarize result). Pick the category axis and the value, and it redraws itself from scratch on every re-run.
Statistics — count, sum, mean, min, max, standard deviation across a column, so a number can be sanity-checked instead of eyeballed across thousands of rows.
What closes the loop is export. From any point in the recipe — not just the final step — you can export the current table back out as an Excel workbook or a CSV, ready to email, upload, or hand off. Export to Excel supports multiple named sheets in one workbook (so a summary tab and a detail tab can travel together), currency/number/percent formatting per column, and a file-naming template with placeholders like {date}, {source}, and {step} — so "this month's aging report" doesn't need to be renamed by hand before it goes out.
In a spreadsheet, "send the aging report" means manually formatting a tab, hiding helper columns, renaming the file with today's date, and re-doing every bit of that by hand next month.
In BeAutomating, export is the last step of the same recipe: point it at the Aging Buckets output, name the sheet, set the formats once, and let {date} fill in the filename automatically — every future run produces the same clean, correctly named handoff.
Do it
- Using the per-customer summary table from Lesson 2.4 (or rebuild it: Group & Summarize by
customer, sum ofamount), confirm you still have the Chart and Statistics steps from Lesson 2.6 attached, or add them now. - Click Export on the summary table and choose Excel. Name the sheet something recognizable, like "Customer Totals," and set the amount column's format to Currency.
- In the filename field, use a template like
{source}_summary_{date}.xlsxand confirm the preview shows today's date filled in automatically. - Run the export and open the resulting file outside BeAutomating — confirm the sheet name, the currency formatting, and the row data all match what you saw in the app's preview.
Check
You export the same recipe's result today, and again next month after re-running it on new data. Do the two exported files have the same name?
No — and that's the point. Because the filename uses a {date} placeholder rather than a fixed name, each export resolves to a different, correctly dated file automatically: invoices_summary_2026-07-28.xlsx today, invoices_summary_2026-08-26.xlsx next month. You never rename anything by hand, and two months' worth of exports never silently overwrite each other in a shared folder.
Module 4 · Reuse & scale
Save a recipe, re-run on new data
Concept
Everything up to this point built a recipe once, lesson by lesson, and admired it working on the file you started with. This lesson is the payoff that whole build-up was for: every recipe in BeAutomating can be saved a single time and re-pointed at a new file, unchanged.
On screen, the action is 💾 Save as Template, sitting above the step list. Give it a name and, optionally, a description and a few tags — the dialog's own placeholder, Monthly GL Accruals, is a good model: task plus cadence. What gets saved isn't a snapshot of today's numbers. It's the recipe itself — the ordered list of steps, plus the list of column names it was built against.
Next month, when you drop in a new file whose columns are at least mostly the same as what the recipe remembers, BeAutomating recognizes it and shows a banner: "This looks like [your template name]" with Apply Template and Dismiss. Click Apply Template and every step you built — Clean, Reshape, Calculate, Summarize, whatever the chain was — re-runs against the new file's table, in order, in seconds.
In a spreadsheet, "the same report on this month's export" means reopening last month's workbook, re-pointing every formula and pivot at the new tab, re-checking each one by eye, and doing it all again next month — twenty minutes to an hour, every single time, forever.
In BeAutomating, that twenty minutes of thinking happened once, when you first built the recipe. Every run after that is Apply Template and a few seconds of the engine re-executing steps you already trust.
Do it
- Open a recipe you built earlier in this course — the messy-invoices cleanup chain from Lesson 3.2 or the export recipe from Lesson 3.3 both work. Click 💾 Save as Template.
- Name it something you'd recognize in a list six months from now, add a one-line description of what it does and who'd use it, then save.
- Get a "next month's" version of your source file — a copy of the same file under a new name is fine, or a genuinely different export with the same columns is even better. Import it as a new table.
- Watch for the "This looks like [your template name]" banner. Click Apply Template and time how long it takes for every step to re-run against the new table.
Check
You spent twenty minutes building a five-step recipe the first time, against this month's file. How long does it take on next month's file, once you click Apply Template?
Seconds. The twenty minutes of thinking — which step, in which order, on which column — doesn't repeat; only the run does. That's the entire pitch of this course, made concrete: hours of manual rebuilding, every month, forever, collapses into one click after the recipe exists once. Compare that to redoing the same report by hand in a spreadsheet, from scratch, next month.
Module 4 · Reuse & scale
Finance templates
Concept
You don't have to start every recipe from a blank canvas either. The moment you import a file, BeAutomating looks at your column names and tries to recognize what kind of financial data it is — general ledger, accounts payable, accounts receivable, expenses, sales, or inventory — the same way you'd recognize an AR aging export at a glance from seeing "customer," "due date," and "amount" sitting together.
When it recognizes a shape, the Steps panel header reads "Detected: Accounts Receivable —" (or whichever type matched), and a small set of steps is already sitting there, pre-built and named, ready to run — not an empty panel waiting for seven trips through + Add Step. What gets generated per type is real:
General Ledger (debit + credit columns) — Trial Balance, Net Balance by Account, and, if a department column exists, Journal Summary by Department.
Accounts Payable (vendor + due/invoice columns) — AP Aging Report, Payables by Vendor, and, with a status column, Payables by Status.
Accounts Receivable (customer + due/receivable columns) — AR Aging Report and Receivables by Customer.
Expenses (category + expense/claim columns) — Expenses by Category, plus Expenses by Employee and Pending Approvals when those columns exist.
Sales (product + quantity + price/revenue) — Revenue by Product, Revenue by Region, and a Product × Region Matrix pivot when a region column exists.
Inventory (stock/reorder + product) — Reorder Alerts (Below Threshold) and Stock Valuation.
These aren't placeholders you have to trust blindly — each one is a real step, mostly Group & Summarize or Aging Buckets under the hood, the exact steps you already know by name from Module 2, already pointed at the right columns for the file you just imported. Your job is to look at what got generated, decide which ones you actually need, and adapt the rest.
Blank canvas: import a file, stare at an empty Steps panel, and reconstruct "AR aging by customer" from memory — pick Summarize, pick Aging Buckets, pick the right columns, the same sequence you practiced by hand in Lesson 2.4.
Finance template: import the same file, and AR Aging Report plus Receivables by Customer are already there, already pointed at customer, due_date, and amount. You're editing a report that's already ~80% right, not building one from nothing.
Do it
- Import a file shaped like accounts receivable — columns for customer, a due date (or "receivable"), and an amount. Reuse your invoices file from Module 2 or 3 if it already has those columns.
- Look at the Steps panel header. Confirm it reads "Detected: Accounts Receivable" with two steps already present: AR Aging Report and Receivables by Customer. Run each one's ▶ and look at the output.
- Pick one of the two generated steps and adapt it — open AR Aging Report and change a bucket boundary, or add a Filter step after Receivables by Customer to show only customers above some amount. You're editing a real report, not building one from zero.
- Compare: how long did it take to get a usable AR aging report starting from the template, versus how long Lesson 2.4 took you to build the equivalent Group & Summarize + Aging Buckets chain from the blank picker?
Check
Your file has customer, due_date, and amount columns, but the Steps panel header still says "Detected: Generic" with no pre-built steps. What's the most likely reason?
Detection looks for a recognizable combination of column names, not just any one of them — for Accounts Receivable specifically, a customer-like column plus a due-date or receivable-labeled column, while also checking the file doesn't also look like a sales export. If one of those column names doesn't closely match what the detector expects — a due-date column with an unusual header, say — the pattern won't fire and you land on Generic with an empty step list, same as any file with no recognizable shape. That's fine: you build the recipe by hand exactly as you did in Module 2, and it's just as real and just as reusable once saved.
Module 4 · Reuse & scale
Parameterizing / adapting
Concept
Lesson 4.1 showed the ideal case: a new file whose columns matched what the recipe expected, and Apply Template just worked. Real files aren't always that tidy — an export tool renames "Customer" to "Customer Name," a new region adds a column the old recipe never saw, or a "similar" sheet turns out to be from a slightly different report entirely. This lesson is about that gap.
A saved recipe remembers the column names it was built against. A new file matches well enough to trigger the "This looks like..." banner when most of those names — case differences aside — are still present. Rename or drop a couple of columns and it usually still matches; rename or drop several and the banner simply won't appear, or a step that references a name the new file doesn't have will error or come back blank once you apply it.
What to check when a match doesn't happen, or a step looks wrong after applying one:
1. Compare column names exactly — not just visually similar ones. "Customer" and "Customer Name" are different strings to a step that expects one specific name.
2. If the data is the same but the header changed, add a Clean → Rename / Select Columns step at the very front of the recipe, mapping the new name back onto the name every later step already expects. Fix it once, at the front, instead of touching every step downstream.
3. If a column a step needs is genuinely missing — not renamed, actually absent — find that step and either point it at the closest equivalent column or accept that this file can't run that particular step.
4. Extra columns the old recipe never saw are harmless — steps that don't reference them simply ignore them.
In a spreadsheet, "a similar workbook with one renamed column" usually means re-checking every formula that referenced the old header, one by one, hoping you find them all.
In BeAutomating, one Rename / Select Columns step at the top of the recipe maps the new name back to the old one — every step after it keeps working exactly as written, with zero edits.
Do it
- Take a recipe you saved in Lesson 4.1 (or build a small one now) and open the source file it was built against. Note two or three of its column names exactly as written — capitalization and spacing included.
- Make a "new-but-similar" version of that file where one or two of those column names are different — rename
CustomertoClient Namein a copy, for instance — while the data underneath stays the same. - Import the changed file and check whether the "This looks like..." banner appears. If it doesn't, or a step errors after you apply it, add a Clean → Rename / Select Columns step at the top of the recipe that renames
Client Nameback toCustomer(and anything else you changed). - Re-run the recipe from the top and confirm every step downstream — the ones written against the original
Customername — now works against the renamed sheet with zero edits to those steps themselves.
Check
Your saved recipe expects five columns. The new file has four of the original names plus one renamed column. Does the "This looks like..." banner still appear?
Most likely yes — four of five names still match, which is enough to clear the match threshold, so the banner still offers itself even though one column changed. That's not a guarantee every step will run cleanly, though: whichever step actually reads the renamed column may still error or come back blank once you apply the template. Treat a successful match as "probably the right recipe," then check each step's output before trusting it — the same habit as every other Check in this course.
Module 5 · AI, sharing & troubleshooting
The AI step
Concept
Every step you've built so far — Clean, Reshape, Calculate, Summarize, Arrange — is deterministic. Same input, same step, same output, every single time, forever, with nothing leaving your machine. That's most of what a real automation needs, and it's why Modules 1 through 4 never mentioned AI at all. But some columns genuinely can't be filled by a formula: "what category does this vague expense description belong to," "is this support ticket urgent," "summarize this free-text comment in five words." That's what the AI step is for.
Add one from the step picker and you pick a column to work on — a description, a comment, a free-text field — and a provider: Claude, OpenAI, or a local model if you've got one configured. The step sends each row's value out (or, for a local provider, keeps it entirely on your machine) and writes the result back as a new column: a category, a sentiment, a short summary, whatever you asked for. It behaves exactly like any other step in the chain — it has an ▶ to run, it sits between the steps before and after it, and it re-runs the same way when you Apply Template on next month's file.
Two things make it different from every other step in this course, though, and both matter. First — it's opt-in and it may need a key. A deterministic step like Group & Summarize just runs; an AI step needs a provider configured — Claude or OpenAI need an API key you supply, and cloud providers can be blocked entirely if your privacy mode is set to Strict, in which case you'd switch to a local provider or skip the step. Nothing about your recipe requires it. Second — think of it as one step over the whole table, not per-row magic. You're not asking AI to run your entire recipe; you're asking it to fill in one column, once, for rows that need it, the same way Calculate fills in one formula column. Everything before and after that step in the chain stays exactly as deterministic — and exactly as local and private — as it always was.
Use a deterministic step (Filter, Case-When, Group & Summarize…) whenever the rule is a rule — "amount over $500," "status equals overdue," "sum by vendor." It's instant, it's free, it's 100% consistent, and it never leaves your machine.
Reach for the AI step only when there's no rule to write — the column is free text, and what you need out of it (a category, a sentiment, a one-line summary) is a judgment call, not a formula. If you catch yourself trying to write a Case-When with fifteen branches to categorize messy text, that's usually the tell that an AI step is the better fit.
Do it
- Open a recipe with a free-text column that doesn't fit a clean rule — an expense description, a support-ticket comment, anything you'd struggle to categorize with Filter or Case-When.
- Add an AI step from the step picker. Point it at that free-text column and ask for one clear thing: a category, or a one-line summary — not both at once.
- If no provider is configured yet, you'll be prompted for one — Claude or OpenAI with an API key, or a local model if you have one set up. Confirm which provider you picked and whether it's cloud or local.
- Run the step and look at the new column it produced. Spot-check five rows by eye: does the category or summary actually match what you'd have written yourself?
Check
You need to flag every row where "amount" is over $500. Should that be an AI step or a deterministic step?
Deterministic — a Filter or Case-When step with the rule "amount > 500." There's an exact rule here, it needs no judgment, and a deterministic step is instant, free, 100% consistent, and never leaves your machine. Save the AI step for the column where you genuinely can't write a rule — free text that needs a judgment call, not a threshold.
Module 5 · AI, sharing & troubleshooting
Sharing recipes
Concept
Every lesson so far has been about you building a recipe and re-running it yourself. This one is about handing it to someone else — a teammate who needs the same monthly AR aging report, or the same expense cleanup, but who never built a single step of it and doesn't need to. This is the third leg of a pattern worth naming: you learn a thing yourself, you let AI help where it earns its place, and then you hand the finished, working result to others who don't need to relearn any of it from scratch. Module 5 has walked that exact path — Lesson 5.1 was AI helping where a rule couldn't; this lesson is others.
The mechanism is the same 💾 Save as Template button from Lesson 4.1 — a saved recipe is already a self-contained file: the ordered list of steps, plus the column names it expects, nothing else. Share that file with a teammate — however your team already moves files around, this course doesn't require anything new — and they import it into their own BeAutomating the same way you'd import a file you saved yourself.
From your teammate's side, the whole history of how the recipe was built is invisible, and that's the point. They don't see the twenty minutes you spent testing Aging Buckets thresholds in Lesson 2.4, or the Rename step you added in Lesson 4.3 to handle a renamed column. They see a name, maybe a description if you wrote one, and a banner offering to apply it the moment they import a matching file. They click Apply Template, the same button you've clicked all through Module 4, and every step runs — including any AI step from Lesson 5.1, provided they have their own provider configured, since your API key doesn't travel with the recipe.
In a spreadsheet, "share this report with a teammate" usually means either sending them a workbook full of formulas they're afraid to touch, or writing up a set of instructions for them to redo by hand — either way, your knowledge doesn't actually transfer, just a static result or a page of steps to re-learn.
In BeAutomating, the recipe itself is what transfers. Your teammate re-runs your exact thinking against their own file without needing to understand a single step inside it — the same Apply Template action you've been using on yourself since Lesson 4.1, just pointed at someone else's import instead.
Do it
- Pick a recipe you've already saved as a template — the AR aging one from Module 4, or the AI-enriched one from Lesson 5.1 both work.
- Note its name and one-line description as if you were handing it to a teammate cold — would they know what it does and what file to run it on, from that alone? Tighten the description if not.
- Hand the recipe to a stand-in "teammate" — a second BeAutomating install, a colleague, or even just yourself pretending not to know how it was built. Have them import a matching file and click Apply Template without any explanation from you beyond the recipe's own name and description.
- Confirm every step ran end to end for them, including any AI step, and that the final output looks the same as when you ran it yourself.
Check
Your recipe has an AI step using your personal Claude API key. Your teammate applies the template on their own machine. Does the AI step run for them?
Only if they've configured their own provider — your API key doesn't travel with the saved recipe, the same way none of your data does. What transfers is the step itself: which column it targets and what it's asking for. If your teammate hasn't set up a Claude, OpenAI, or local provider on their end, that one step will need their configuration before it can run — every deterministic step around it, though, works immediately with no setup at all.
Module 5 · AI, sharing & troubleshooting
Reading a failed step
Concept
Sooner or later, on some file, some step is going to turn red. That's not a sign this course skipped something — it's the normal cost of pointing a saved recipe at data it wasn't originally built against, and it's the last skill this course teaches: a failed step isn't a dead end, it's feedback telling you exactly what changed. Read it, fix the one thing it's pointing at, and re-run — the same habit as every "Check" question you've answered since Module 1, just triggered by the engine instead of by a question on this page.
A red step means the engine tried to run and couldn't — it stops at that step and shows you why, rather than silently producing a wrong or empty result. The message is specific to what went wrong. Walking backward through this course, the causes you're most likely to hit map directly onto lessons you've already done:
A referenced column doesn't exist — the exact scenario from Lesson 4.3, where a file's column was renamed or dropped. Fix: add or check the Rename / Select Columns step at the top of the recipe.
A type mismatch — a step expecting numbers hits text, often because a currency symbol or stray character survived import, the same messy-export problem from Lesson 3.2. Fix: add or check a Fix Data Types step before the failing one.
A join or lookup finds nothing to match — the two tables in a Join / Lookup step (Lesson 2.2) don't share the key you expect, often because of a formatting difference like leading zeros. Fix: check both key columns' formatting before the join.
An AI step comes back empty or errors — from Lesson 5.1: no provider configured, an invalid or expired API key, or cloud providers blocked under Strict privacy mode. Fix: set up or check the provider, or switch to a local one.
A licensed feature is locked — some steps and templates are Pro features, gated by a license check. If your license is on the free or trial tier, that step shows as locked rather than red-failed — the fix there isn't a data fix, it's upgrading the license, not something to debug in the recipe itself.
How to fix and re-run
Click the failed step to open its message and see exactly which column or setting it's complaining about. Fix that one thing — rename a column, add a type-fix step, reconfigure a provider — then re-run just that step with its own ▶, rather than the whole recipe from the top. If it turns green, run the rest of the chain after it to confirm nothing downstream was also affected.
In a spreadsheet, a broken formula often fails silently — a #REF! error buried in one cell of thousands, or worse, a wrong number that looks plausible and goes unnoticed for months.
In BeAutomating, a failed step stops the chain and tells you exactly where and why, before a wrong number ever reaches your output. That's a feature, not a flaw — treat every red step as the engine doing its job.
Do it
- Take a working recipe from earlier in this course and deliberately break it — rename a column the recipe depends on, or feed it a file with a formatting quirk you know will trip a type check.
- Run the recipe and find the step that turns red. Click it and read the exact message — which column, which setting, which value.
- Match the cause to the list above (missing column, type mismatch, join with no match, AI provider issue, or licensed feature) and apply the corresponding fix.
- Re-run the fixed step, confirm it turns green, then re-run the rest of the chain and confirm the final output is correct again.
Check
A step that used to work turns red after you apply a saved template to a new file. What's your first move — rebuild the recipe from scratch, or something else?
Something else — click the failed step and read its message first. A red step after applying a template almost always means the new file differs from what the recipe expects in one specific way: a renamed column, a type quirk, an unmatched join key. That's a targeted, one-step fix, not a reason to rebuild anything. Rebuilding from scratch throws away a working recipe to fix a problem that's usually one Rename or Fix Data Types step away from solved.