Verified against ChatGPT · 2026-08-10
Write a Google Sheets formula that won't quietly break when three other people are editing the same sheet
Builds a Google Sheets formula for a specific calculation with explicit safeguards against the failure modes unique to a shared, live-edited sheet — inserted rows, someone typing over a reference cell, and stale cached values.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You're helping build a formula for a Google Sheet that isn't just used by me — it's a live, shared sheet that a few other people edit directly, which creates failure modes a single-user spreadsheet doesn't have. CALCULATION NEEDED Flag any row where actual spend exceeds 110% of the budgeted amount for that line item. SHEET LAYOUT Column C = budgeted amount, Column D = actual spend, both starting row 3; row 1-2 are merged header cells. WHO ELSE EDITS THIS SHEET Two project managers who update actual spend weekly by typing directly into cells, neither is comfortable with formulas. HOW IT'S USED DOWNSTREAM A conditional-formatting rule and a summary pivot on a second tab both reference this flag column. Build the formula, then check it specifically against these shared-sheet risks: - Would this formula silently break or shift incorrectly if someone inserts a row in the middle of the range it references? - Does it rely on any cell reference that a non-technical collaborator might reasonably type over (a hardcoded threshold value sitting in a random cell versus a labeled input cell)? - If this feeds a chart, pivot table, or another sheet via IMPORTRANGE, will a formula error in one cell (like #REF!) propagate and silently break those downstream views, or fail loudly enough that someone would notice? If the answer to any of those is "yes, it would break silently," revise the formula or the sheet structure recommendation to close that gap — for example, using whole-column or named-range references instead of fixed cell ranges, or pulling a hardcoded value out into a clearly labeled, protected input cell. WHAT NOT TO DO Do not recommend a structural change (like protected ranges or a separate inputs tab) without explaining specifically which risk it closes — every recommendation should map to one of the three risks above, not be generic "best practice" advice. OUTPUT FORMAT 1. The formula, ready to paste. 2. For each of the three shared-sheet risks: does it apply here, and if so, what was changed to address it. 3. Any sheet-structure recommendation (named ranges, a protected inputs tab, etc.), each tied explicitly to a named risk. 4. One line noting if any risk remains open and why it's acceptable to leave it, if you conclude that.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Framing the risks specifically around a shared, live-edited sheet — rather than asking generically for a good formula — targets a category of failure that only exists because other people are editing the file, which a model has no reason to consider unless the collaborative context is stated: a formula that's perfectly correct in isolation can still break the moment a non-technical collaborator inserts a row above the referenced range, since a fixed range reference doesn't always auto-adjust the same way a whole-column or named range does. Asking explicitly whether a hardcoded value sits in a cell a collaborator might type over addresses a very common, very quiet failure in shared sheets: someone updates what they think is just a number and doesn't realize it was actually a threshold the whole calculation depended on, and the sheet keeps producing numbers that look plausible but are now wrong. Requiring the propagation check on IMPORTRANGE and downstream pivots or charts matters because Google Sheets error propagation is not always obvious to the person actually looking at the summary tab — a #REF! error two tabs upstream can resolve into a chart that just quietly shows a shorter data range or a stale cached value instead of an obvious red error cell, which is far more dangerous than a loud failure because nobody investigates a chart that still looks fine. Tying every structural recommendation to a specific named risk, rather than allowing generic "best practice" advice, keeps the model from padding the answer with boilerplate like "consider using named ranges" without ever connecting that suggestion to an actual failure mode present in this specific sheet.
What you get back
=IF(D3:D="","",IF(D3:D>C3:C*1.1,"Over budget","OK")) using a whole-column ARRAYFORMULA reference rather than D3:D200, so a row inserted anywhere below row 3 is automatically included. Risk check: row-insertion risk closed by using whole-column references; the 1.1 threshold is currently hardcoded in the formula rather than a labeled cell — recommend moving it to a named cell 'Budget_Threshold' on an Inputs tab so a PM adjusting it doesn't need to edit the formula directly; IMPORTRANGE propagation risk is low here since nothing downstream currently pulls from this column via IMPORTRANGE.
Verified against
ChatGPT GPT-5.1 · 2026-08-10
Changelog
- 2026-08-10 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
