Match the tool to the question
Two tools cover formula work. Each takes one action block named for the action.
A question that existing values can answer stays read-only. A new calculated result needs a visible, saved formula. The user’s request is the authorization to create it; a change that is easy to undo from the changelog needs no separate confirmation.
Start from the visible table
Read the relevant Table block once, reuse the row and column references it returns, and send related edits together. The server derives the Variable, the formula’s scope, and its Date grain from that visible target, and the read tells you whether each cell is writable, so you never build those yourself. The range is the one you name:default_formulas.actuals or default_formulas.forecast.
When the work has no table yet, read the existing Variables and Dimensions first, and reuse their returned references, such as Revenue#3f2, when you compose a formula.
Write expressions with readable Variable names. Put backticks around a name that contains spaces, punctuation, or a reserved word, such as `Gross Profit`. Add a returned reference’s short suffix only when two names collide.
Respect the Scenario
Formulas are Scenario-scoped. Use the Scenario the user is working in, or the one they asked for, and pass it asscenario beside the action block. If a write could reasonably go to more than one Scenario, settle which one before you change the Model.
Keep the condition and the expression apart
A formula has two parts. The condition decides where it applies; the expression decides what it calculates. For a visible table edit, the server derives the condition from the target you choose:- a row’s own formula,
- a
child_defaultsformula that the items beneath a row inherit, or - one cell.