One action answers every "how much, how many, across which items" question a SharePoint process asks. The Calculate Summary action in Ultimate Forms aggregates items in any list, sum, count, average, minimum, maximum, over exactly the items your filters select, and then does one of two things with the answer: writes it into a column on the current item, or raises an error when the answer breaks a rule, which, run synchronously, blocks the save itself. The first mode keeps parent records informed; the second is how double bookings, blown budgets, and premature closures get stopped. This guide covers both modes, the configuration, and the five scenarios that use them. For the engine behind it, see the automation hub.
The questions only aggregation can answer
A single item knows its own values; processes keep asking questions about the neighbors. What do this order's lines add up to? How many reservations already claim this room at this hour? Has this department's spending reached its budget? Are any of this project's tasks still open? None of these is answerable by a column rule on the item, because the answer lives across other items, and natively, the answers are assembled by a human with a filtered view and a habit of being interrupted.
The Calculate Summary action turns the question into configuration. It queries a list, any list, in this site or, via run-time values, another site or site collection, selects items by your filters, aggregates a column, and delivers the answer where the process needs it. The aggregation types cover the arithmetic that business rules actually use: sum and average for amounts, count for existence and workload, minimum and maximum for dates and bounds, with count available on non-numeric columns, and All/Any checks serving the error mode.
Mode one: write the answer
The first mode updates a column on the current item with the summary result, which is how parent records stay honest about their children. The order carries its lines' total; the project carries its open-task count; the department record carries this month's spend. The value is a real column, so everything downstream can read it: views and dashboards display it, alerts condition on it, other rules calculate with it.
The timing is whatever the process wants: on item events when child changes should refresh the parent, on schedules for periodic rollups, or manually from a button when the recount is on demand.
One boundary keeps this mode in its lane. For children of an Associated Items column, the Associated Items Summary column already does automatic, always-current summarization with no action needed, and it is the right tool inside that relationship. The action's territory is everything else: lists without the parent-child column, cross-site aggregation, filters beyond the relationship, event-and-timer-driven recalculation, and above all, the second mode, which no column can do.
Mode two: block the save
The second mode raises an error when the summary fails your condition, and run synchronously, inside the save itself, it cancels the update and shows the user your message while their hands are still on the form. This is enforcement, not reporting: the conflicting reservation never becomes an item, the over-budget expense never saves, the project cannot close while the count of open tasks is above zero.
The canonical build is the double-booking guard, counting reservations with the same resource and overlapping time, erroring when the count exceeds zero, and it has its own dedicated walkthrough, with the broader validation context in real-time data validation. The principle generalizes to any rule whose truth lives across items: aggregate, compare, refuse. Note the comparison direction when configuring, the error fires when the value does not pass the condition, so a no-conflicts rule compares the count with zero, not the other way around, and remember the Synchronous setting under Advanced, without which the check runs after the save it was meant to guard.
The configuration, in order
The setup follows the question's own grammar. Choose the site and list to aggregate from, static, or dynamic through run-time values when the source depends on the item. Define the affected items, at least one filter is required, and the filters are the rule's precision: same room, same date, status Active, this department, this month. Pick the column to summarize and the operator. Then choose the result's fate: update a named column on the current item, or raise an error with a condition and a message. Trigger, conditions, and after-change guards round it out like any action, and the first test should exercise both directions: a case that passes, and a case that must be refused.
Five scenarios, two modes
The reservation guard. Count overlapping bookings for the resource and slot; error above zero, synchronously. The race between two simultaneous bookers resolves correctly because each save checks against whatever committed first.
The budget ceiling. Sum the department's submitted and approved expenses for the month; error when the new submission would cross the budget. The policy that was a spreadsheet reconciliation becomes a refusal at entry, with a message that names the remaining headroom if you write it well.
The order total. Sum the line items into the parent order's Total column on every child change, and let a second, error-mode action hold the floor and ceiling, minimum order values, approval thresholds, enforced at the same moment the total updates.
The completion gate. Count the project's tasks with status not Completed; error above zero when someone sets the project to Completed. The premature closure, the classic data-quality lie, becomes impossible rather than discouraged, the same gate validation rules describe from the form side.
The compliance quota. Count passed inspections among the record's related items; refuse closure until the required number exists. Auditors stop finding closed records with missing checks, because the system stopped permitting them.
Keeping the aggregations healthy
Three disciplines cover the operational side. Filter precisely and index the filter columns: the query runs every time the action fires, and on large lists the difference between a filtered, indexed query and a broad sweep is the difference between invisible and throttled, the same economy the scheduled-actions guide preaches. Write error messages as instructions: "This room is booked 2:00 to 3:30; choose another time" and "2 tasks remain open; complete them before closing" convert refusals into next steps, while a bare "condition failed" converts them into support tickets. And mind permissions: the action reads and writes across lists, so when ordinary users' saves trigger it, the action may need Impersonation to see what they cannot, elevation granted per action, exactly where it belongs.
The deeper point is the one running through the whole actions family: rules whose truth spans items used to be the exclusive territory of custom code, and this action makes them one more configured unit, named, conditioned, logged in Action History, and maintainable by whoever owns the process. Aggregate, then inform or refuse, and most of a solution's cross-item intelligence is covered by those two verbs.
Frequently asked questions
Add your comment
