{"slug": "rollup-vs-calculated-columns-in-dataverse-the-async-trap-we-fell-for", "title": "Rollup vs calculated columns in Dataverse: the async trap we fell for", "summary": "The article explains the critical difference between calculated and rollup columns in Dataverse, highlighting that rollup columns update on a configurable schedule (default every 12 hours, minimum every hour), while calculated columns compute values in real-time when a row is read. The authors describe a real-world scenario where a team mistakenly assumed a rollup column provided real-time totals, leading to stale data on a deal dashboard. They then present three alternatives for achieving current aggregate data: using a plugin to update totals on child record changes, employing a calculated column on child records for read-time aggregation, or adding a manual refresh button to trigger rollup recalculation.", "body_md": "A deal desk dashboard showed the running total of opportunities per account. Total amount per account was a rollup column. Users opened the dashboard, saw a total, made a decision. Then someone added a new opportunity and checked the same account. The account's total did not change.\nFifteen minutes later, refresh - still not changed. An hour later - changed. The rollup column was working exactly as documented, and the team had mistaken it for a real-time aggregate.\nHere is the difference between calculated and rollup columns, and the pattern we now use when the dashboard needs to be current.\nCalculated column: computes its value every time the row is read. If the column adds two other columns, every time anything loads the row (form view, API call, view row), Dataverse computes the sum. Results are always current because they are re-derived on demand.\nRollup column: computes its value on a schedule. The default schedule is every 12 hours, configurable down to one hour per column. A rollup that sums child record amounts reads the current state of children when the schedule fires, stores the result, and serves that stored value until the next schedule.\nBoth store their definition (the formula) in the solution. Both look identical to consuming code. The runtime behavior is radically different.\nCalculated columns are correct when:\nRollup columns are correct when:\nA calculated column that aggregates children is not allowed. Dataverse blocks it - the reason is performance, reading an account would trigger a query across all its opportunities every load. Rollup is the platform's answer: compute the aggregate ahead of time, serve it cached.\nTeams who want a rolling total of child records are usually asked for it by a business user who sees the number on a dashboard and expects it to match reality. When a user tells the team \"the total on the Account form should show all linked Opportunity amounts,\" the team builds a rollup column. The dashboard shows the rollup.\nThe user then creates an opportunity, looks at the account, and the total is stale. From the user's perspective, the number is wrong. From the platform's perspective, the number is accurate for the last time the schedule fired.\nThe fix is either to lower the user's expectations (the dashboard updates on a schedule) or to change the implementation.\nWhen the aggregate genuinely needs to be current:\nAlternative 1: plugin that updates a stored total on every child change.\nA post-operation plugin on Opportunity (Create, Update on amount, Delete) recalculates acme_total_opportunities on the parent Account and writes it. Works for modest volumes - an account with 200 opportunities, each updating rarely, is fine. Fails for accounts with 20,000 opportunities updating frequently - every child change becomes a parent write, and the Dataverse execution pipeline starts throttling.\nGood for: master-detail relationships with medium fanout.\nAlternative 2: calculated column summing via the lookup.\nYou cannot aggregate children from a parent via a calculated column, but you can compute the child's contribution per row using a calculated column on the child. acme_attributable_amount = IF(acme_is_counted, amount, 0) on Opportunity, then use that in any consumer query. The consumer does the aggregation at read time.\nWorks for: dashboards that can run FetchXML with aggregate operators (SUM the acme_attributable_amount across children in a single query). Fails if the consumer is a Dataverse form or view that cannot run aggregate queries.\nGood for: Power BI reports, custom dashboards, anywhere you control the read query.\nAlternative 3: rollup with one-hour schedule plus \"Refresh\" button.\nKeep the rollup for the baseline case. Add a button on the form that explicitly triggers a rollup recalculation via the CalculateRollupField SDK request. User experiences it as \"I just added a child, now I hit Refresh, the total updates.\"\nWorks for: dashboards with bursty usage patterns - the baseline is acceptable, explicit refresh covers the \"just changed it\" case.\nGood for: sales management screens, deal desk reviews, scenarios where users understand the refresh semantics.\nOn any project with more than three rollup columns, we audit quarterly:\nThe audit takes 20 minutes per project. Half the time, at least one rollup can be deleted; a third of the time, at least one schedule needs adjusting.\nA rollup of child-record amounts updates when a child is created or its amount changes. It does not update when a child is deleted, until the scheduled refresh fires.\nThe window between \"child deleted\" and \"rollup refreshed\" shows an overstated total. This is especially painful in audit scenarios - a user deletes a duplicate, the total still shows the duplicate's contribution for up to twelve hours.\nThe fix is either a plugin on the child Delete event (post-operation, trigger a rollup recalculation explicitly via CalculateRollupFieldRequest) or a tighter schedule. We usually go with the plugin when the table supports deletions, because the time-lag is user-visible.\nRollup columns ship with a form tooltip: \"This total refreshes every N hours. Click Refresh after adding new records to see updated totals immediately.\"\nThe tooltip is one field-description line, it costs nothing to add, and it inoculates the \"why is the number stale\" ticket that would otherwise land every other week. Every rollup we ship has it. Every one we inherit gets it added on the first pass.", "url": "https://wpnews.pro/news/rollup-vs-calculated-columns-in-dataverse-the-async-trap-we-fell-for", "canonical_source": "https://dev.to/sapotacorp/rollup-vs-calculated-columns-in-dataverse-the-async-trap-we-fell-for-1mh1", "published_at": "2026-05-24 02:52:20+00:00", "updated_at": "2026-05-24 03:01:42.838703+00:00", "lang": "en", "topics": ["data", "enterprise-software", "developer-tools", "cloud-computing"], "entities": ["Dataverse"], "alternates": {"html": "https://wpnews.pro/news/rollup-vs-calculated-columns-in-dataverse-the-async-trap-we-fell-for", "markdown": "https://wpnews.pro/news/rollup-vs-calculated-columns-in-dataverse-the-async-trap-we-fell-for.md", "text": "https://wpnews.pro/news/rollup-vs-calculated-columns-in-dataverse-the-async-trap-we-fell-for.txt", "jsonld": "https://wpnews.pro/news/rollup-vs-calculated-columns-in-dataverse-the-async-trap-we-fell-for.jsonld"}}