Add calculated fields and running totals

A total worked out for you

Take an expense or order form. Someone enters an item price and a delivery cost, and you want the GST and the total worked out for them, not left to a calculator on the desk. The calculations read like the arithmetic you would write down:

As soon as someone changes a figure, the totals update. When they submit, the calculated values save to the SharePoint list columns alongside the rest of the record, so a report reads the number straight from the list.

More than money

The same idea covers a lot of ground:

• A full name or reference built from a few separate fields.
• A field that becomes required only when another answer crosses a threshold, using cross-field validation.
• A flag that a submission needs review when two answers do not line up.

A reference built from other answers

The other everyday use is text rather than arithmetic. Give every record a readable reference built from what the person already entered, so nobody has to invent one and no two look alike:

Joining text uses the same + you use for numbers. Worth knowing where the line sits, though: it adds numbers when both sides are numbers, and otherwise joins them as text. So it will not do date arithmetic. If you need a due date that is a number of days after a start date, collect both and let the person or a downstream flow work out the date, rather than expecting the form to add days to a date.

Pair a calculation with a check

Where dates do work well is comparison. A calculation fills a value in; a cross-field rule stops a contradictory submission being saved at all:

Those are two halves of the same job, which is why the validation guide and this one keep pointing at each other.

Where the number actually lives

A calculated value on the form is not the same thing as a SharePoint calculated column, and the difference decides where you should put the logic.

A calculation on the form runs while somebody is filling it in, so they see the total before they commit to it. That is what you want for anything the person needs to react to, such as a total that tells them the order is over budget before they submit it. The result is written to the SharePoint list column on save.

The trade-off is that it recalculates when someone opens or edits the form, not when the list changes underneath it. Editing a dependency directly in the list does not update the stored total on its own. For most forms that is the correct behaviour, because you want the number the person actually saw and agreed to. Where you genuinely need a figure that always reflects current data, that belongs in a SharePoint calculated column or a report over the list rather than on the form.

No code, and it runs in the browser

You build the calculation visually rather than writing script. In Forms365 Workspace it runs in the browser while the form is open, so nothing reaches the list until the person saves and the stored record matches what they saw. Forms 365 Web has no-code calculated values too.

Two things worth getting right

Disable calculated fields so they cannot be typed over. If a total is editable, someone eventually will, and you will not know which records were edited by hand.

Do not hide the arithmetic. A form that silently produces a number invites distrust. Showing the subtotal and the GST as separate fields, rather than only a final total, means the person can see how the figure was reached and is far less likely to ring you about it.