SAC Data Actions: copy versions, allocate and spread in SAP Analytics Cloud

Data Actions are what turn SAP Analytics Cloud Planning from a place where you type numbers into a system that calculates them. They automate the repetitive, error-prone steps of a planning cycle: copying a version, pushing a top-down target down to detail, spreading a yearly figure across months, or converting currencies. This guide explains the four you will use most, and the mistakes to avoid.

What a Data Action is

A Data Action is a saved sequence of steps that writes values into a planning model. It runs on demand (a button in a Story) or as part of a process, always against a chosen version. Because it writes data, it only exists in Planning models — an Analytics model has nothing to write to. If you are still deciding between the two, our guide on the difference between SAC Analytics and Planning settles it in one question.

1. Copy — seed one version from another

The most common step. You initialise next year's Budget from this year's Actual, or create a Forecast from the latest Budget, without re-keying anything. In the Data Action editor, add a Copy step, set the source version and the target version, and optionally apply a factor (for example 1.03 for a flat 3% uplift). Copy respects the Version dimension, so Actual stays untouched while the new Budget is built beside it.

2. Allocation — push a top-down number to detail

Management sets a total — say a regional sales target — and you need it distributed across products and channels. An Allocation step spreads the parent value to its children using a driver: equally, by a reference measure (last year's mix), or by weights you define. This is the backbone of top-down planning. The key discipline is choosing a stable, meaningful driver; allocating by a noisy or near-zero base produces nonsensical splits.

3. Spreading across time

An annual figure rarely lands evenly across twelve months. A spreading step distributes a yearly amount over the period dimension using a seasonal profile — flat, by prior-year seasonality, or a custom curve. Combined with the time dimension, this is how a single budget number becomes a monthly plan you can track against Actual.

4. Currency conversion

If your model holds amounts in several currencies, a Currency Conversion step translates them into a reporting currency using a rate table, so consolidated figures are comparable. Keep the rate table itself versioned (Actual rates vs planning rates) to avoid silently mixing assumptions.

Chaining steps and triggering

Real cycles chain several steps in order — copy, then uplift, then spread — inside one Data Action, or orchestrate multiple Data Actions in a Multi Action with parameters. Expose the final action as a button in the planning Story so contributors run it themselves, and scope it tightly to the version and entities it should touch. A Data Action that writes broadly is hard to undo.

Common pitfalls

Three recurring mistakes: running a copy into a public version everyone sees before it is validated (work in a private version first); allocating on a driver that contains zeros or negatives; and forgetting that a Data Action overwrites — it does not merge. Always test on a sandbox version before wiring it to a button.

Start from a Planning-ready model

Data Actions need a model built with a Version dimension and a clean time frame. The Planning-category templates in our catalogue ship with exactly that structure — for example the annual budget template, ready for copy, allocation and spreading out of the box. You can also compose your own with the template generator and add Data Actions on top.