Most Anaplan teams have now heard the pitch for Anaplan Data Orchestrator (ADO): stop doing data preparation inside a Data Hub model, and do it in a governed layer that sits between your source systems and your planning models. We have written before about when to choose Data Orchestrator over CloudWorks or Anaplan Connect. This tutorial is the other half: what you actually click, in what order, to get a working end-to-end flow — and the design decisions at each step that determine whether the thing is still maintainable in a year.
The worked example is a common one: actuals and cost centre master data landing in a cloud warehouse and a CSV drop, joined and aggregated in ADO, then pushed into a financial planning model.
Before you start: access and vocabulary
You need to be an integration administrator in the tenant. If Data Orchestrator does not appear in your top-left navigation menu, that is the reason; a tenant administrator has to grant it. Expect this to take longer than the build itself in a large organisation.
Five nouns carry the whole model, and it is worth learning them precisely because they map one-to-one onto screens in the left-hand panel:
| Object | What it is |
|---|---|
| Dataspace | An access-controlled partition holding your ADO objects. Most tenants have one default dataspace; larger ones separate by region or business unit. |
| Source dataset | Data imported into ADO from a connector, an Anaplan model, or a local CSV. |
| Transformation view | A configured view over a dataset — joins, filters, formulas, aggregation. Its output is called a derived dataset. |
| Link | The mapping that pushes a dataset into objects in an Anaplan model. |
| Pipeline | Automated movement between ADO and an external system: a read pipeline brings data in, a writeback pipeline sends data out. |
The order of the build follows that table: dataspace, source data, transformation view, link, and then pipelines and workflow to automate it.
One structural constraint to internalise early: you cannot move or copy objects between dataspaces. If your tenant has several, decide where an object belongs before you build it, not after.
Step 1 — Choose (or create) a dataspace
Open Data Orchestrator from the navigation menu and you land on the dataspace inventory screen, which lists only the dataspaces you have access to. If you already used ADO before dataspaces existed, Anaplan created a default dataspace and moved your objects into it — one per region if you run ADO in multiple regions. The default dataspace cannot be deleted.
Our guidance for most clients: start with one dataspace. Split only when you have a genuine access boundary — a business unit whose HR or payroll data other integration administrators should not see, or a regional data-residency requirement. Every extra dataspace is a boundary you will later want to cross, and the only supported crossing is virtual datasets (below).
Step 2 — Bring the source data in
From Source data, you can create a source dataset from three places:
- A connection to an external source system. Create the connection first from the Connections screen with a supported connector, then extract from it.
- An Anaplan model. Useful for reference data that is already mastered in Anaplan, and for reading a model's output back out for downstream use.
- A local CSV file. Ideal for prototyping and for genuinely manual reference tables.
For our example we create two source datasets: SRC_GL_Actuals from the warehouse connection, and SRC_CostCentre_Master from a CSV.
A few habits that pay off:
- Name datasets with a prefix that says what they are (
SRC_,TV_,LNK_). ADO inventories get long fast, and the search field is your only navigation once you pass fifty objects. - Import wide, not narrow, on the first pass. Pulling extra columns you might need is cheaper than re-extracting later, but keep an eye on storage: a package carries a soft limit of 25 GB of managed data and 250 datasets, with hard limits at double that.
- Check for a natural key on the way in. If the source has no stable key you can join on, that problem does not get better later in the flow.
Note also that table-based data in ADO has no inherent row order. Sorting exists in the preview only, and a sort you apply in the preview is not saved. If order matters to your model load, order has to come from a column, not from the way the rows happen to sit.
Step 3 — Build the transformation view
This is where ADO earns its keep, and where the Data Hub logic you are retiring actually goes.
Select Transformation views → Create view, name it (TV_Actuals_ByCostCentre), and choose a primary dataset — either a source dataset or another derived dataset. On the Source columns page, pick the columns you want; they appear in the Output columns pane, where you can rename them to match your Anaplan line item names. Do that renaming here, not in the link mapping: it makes the mapping step almost self-documenting.
Then layer on the operations you need:
Join. Select Join, choose the second dataset, and pick the join type:
- Inner join keeps only rows with matching values in both datasets. Use it when an unmatched row is a data error you want to drop.
- Lookup keeps every row from the primary dataset and adds columns from the joined dataset, leaving NULL where nothing matched.
In practice, use Lookup for enrichment — attaching cost centre attributes to GL rows — precisely because the NULLs are visible. An inner join silently deletes the rows your finance team will later ask about. If you want the rows gone, delete them deliberately with a filter after you have counted them.
Union. Combines rows from two datasets and removes duplicate values. This is the tool for stacking regional extracts with identical shapes.
Column formulas. Select a column header and choose Edit to define a formula using the Data Orchestrator function set. This is where you build the concatenated codes Anaplan needs (Entity_CostCentre_Account), normalise sign conventions, and standardise date formats. One warning worth repeating: ADO stores and displays datetime values in UTC, so if your source timestamps carry an offset, convert explicitly rather than assuming.
Filter and aggregate. Filters trim rows. For aggregation, open the ellipsis in the toolbar, select Aggregate, switch aggregation on, and set the Group by behaviour per column. Aggregating in ADO instead of in Anaplan is often the single biggest win of the whole exercise: pushing 400,000 pre-aggregated rows rather than 40 million transaction rows changes both load time and model size.
Data types. Set them here. A numeric column arriving as text will fail a model load in a way that is far more annoying to debug at the link than to fix at the view.
How much logic belongs in ADO?
Our rule: shaping belongs in ADO, planning logic belongs in the model. Joins, filters, code construction, currency-code standardisation, and aggregation to the grain the model needs — all ADO. Allocation drivers, seasonality, phasing, anything a planner might want to interrogate or change — model. The test is whether a business user would ever ask "why is that number what it is?" If yes, the calculation should live where they can see it.
Step 4 — Create the link and push to the model
Links are the final step of the ADO process: create a link to objects in a model, choose a dataset input, map columns to the model objects, then push.
Practical notes from real builds:
- Load lists before modules. Same discipline as classic Anaplan imports — the list has to exist before the transactional data can find it.
- Map to a saved view, not to a raw module, wherever the model side allows it. It gives you a stable contract that survives model changes.
- Watch your allowance. Model links and data extract syncs are metered in a rolling 24-hour period — a package allows 500 model links and 200 data extract syncs (soft), with hard limits at 1,000 and 500. A chatty every-15-minutes design burns through that quickly. Also note that only five processes execute concurrently, and that ceiling does not scale with extra packages.
- If you are migrating, ADO can migrate existing model actions into links, and migrated actions appear on the Links inventory screen. That is usually a better starting point than rebuilding mappings by hand.
Step 5 — Automate with pipelines and Workflow
A read pipeline imports data from an external source system into a new or existing source dataset. As of writing, read pipelines support connections to Amazon S3, Azure Blob Storage, Databricks, Google Cloud Storage, Microsoft SQL Server, and MySQL. A writeback pipeline sends data from a source or transformation view dataset back out to an external system — the mechanism to get approved plan numbers back into the warehouse where the rest of the business reports from.
When you create or edit a pipeline, use the add icon between Source and Sink to insert steps:
- Validate — rules that check data quality and integrity as the data flows through.
- Remove duplicates — drops duplicate rows.
Add at least one Validate step to every production pipeline. A pipeline that fails loudly on a null cost centre is worth ten pipelines that quietly load rubbish into a model the CFO is about to read.
Finally, wire the pipeline into Anaplan Workflow as a Data Orchestrator step, so the data movement runs on a schedule or as part of a larger sequence — extract, validate, load, then the human approval tasks that follow it. That is the piece that turns a set of ADO objects into an actual month-end process, and it pairs naturally with the approval chains you may already be running.
Step 6 — Prove it with the map, then hand it over
Open Map in the left-side panel. It renders nodes for sources, transforms, model links, and models, and shows how data flows between them. Select a node to see its details and jump straight to the object; anchor the view with Set search node to see everything upstream and downstream of one dataset.
Use the map for three things: verifying that the flow you built matches the flow you designed, impact analysis before you change a column, and — the one people forget — handover. A screenshot of the map with a one-page table of object names is a better runbook than any document you will write from scratch.
A short checklist before you call it done
- Every dataset, view, and link follows a naming convention a stranger can read.
- Aggregation happens in ADO, at the grain the model actually needs.
- Enrichment joins are lookups, and NULLs are handled explicitly.
- Every production pipeline has a Validate step and a defined failure owner.
- Load frequency is inside your daily link and sync allowance, with headroom for reruns.
- Datetime handling is explicit, given UTC storage.
- The map has been screenshotted into the runbook, and a second person has run the flow once.
Where we help
We build ADO landscapes from scratch, and we migrate Data Hub logic into them without breaking the models that depend on it — usually as part of our Anaplan Data Integration Services and Anaplan Business Process Integration work. If your integration layer is currently a Data Hub plus a folder of scripts nobody wants to touch, that is a normal starting point. Get in touch and we will scope the migration one pipeline at a time.