Consume

Planual rules for Core integration.

Ensure the Anaplan model workspace has enough free space before pushing large data through the Anaplan Data Orchestrator link.

If the workspace size is insufficient, you may encounter an issue where no list members are added in Anaplan when data is pushed to a list, even though the link push completes with a 'completed' message.

The link performance is optimal if the input dataset includes just those columns that are needed.

We have observed that the presence of superfluous columns has a negative impact on the time required to update lists and modules.

This reduces the volume of data pushed to the model. The more duplicates that exist in the original source data, the greater the benefit of removing these when updating the model.

We have observed that exporting data from tables results in larger file sizes and that pushing data from the source data can take longer. These effects can be minimized by using a view or transformation instead. This also helps with maintenance, since it makes it simpler to amend the definition of a view that a link is based upon.

This complicates the mapping process.

In Data Orchestrator, we require that code be mapped for numbered lists and that name be mapped for standard lists. When you map with name, the code is considered an attribute to be updated. We recommend that you work with numbered lists that are also tagged as Production Data.

If you pull numbered lists from an Anaplan model into Data Orchestrator (which will be pushed back into numbered lists), ensure that you either include or generate a unique code. The generated item number isn't included in the export from the model.

There are two versions of core integration currently in the production environment. Customers starting to use ADO after January 26, 2026 will default to V2 while earlier customers are on V1. Tenants can be moved from V1 to V2, and back to V1 if necessary.

The version of core integration that a tenant is on can be seen in the right-hand panel on the Links inventory page. Select any link and the version is at the bottom of the right-hand panel.

The previous version has been retained as there are changes in behavior in V2 that can impact the data pushed into a model as follows:

• When exporting data from a model saved view into ADO, the line-item order in the view isn't honored in the columns of the source dataset.
• An UPSERT model link in V2 simulates the action "clear target prior to import," while V1 simulates "only update imported cells”. REPLACE clears all cells.
• Exports of modules use code rather than name for dimensions based on numbered lists. For a standard list, users can choose to use name or code.
• When syncing dates from ADO into a module that are invalid, the new API clears the value of the model for both Upsert and Replace on failure. Previously, values were only cleared as part of a replace.
• Hierarchy auto-balancing will generate “dummy members” at lower levels, as well as intermediary levels when these are missing.

V2 of core integration uses a dedicated core API that provides advantages over V1:

• Delivers improved performance.
• Model links no longer create an ADO action in the model, simplifying the model.
• Links provide the option to match on code or name when updating a standard list.
• When exporting data from a module with a line item of type list, and that list is a standard list, the export can be configured to export the name or the code.
• There is the option to match on code or "default" (meaning name for standard lists and code for numbered lists) when updating a hierarchy.
• When using the REPLACE mode, the removal of unwanted list items is performed directly by core and not a series of list item deletes executed from ADO, which drastically improves the performance of this mode.
• Balancing of hierarchies is now performed as an internal transformation rather than in memory, making this more scalable.
• The removal of duplicates when updating the aggregate level lists in a hierarchy is now performed as an internal transformation rather than in memory, making this more scalable and ensuring that entries that have inconsistent parents are identified and correctly reported.
• There is the option to include or omit summary items when exporting data from a model saved view into ADO.
• Boolean line items accept the following as valid values: t/f, yes/no, TRUE/FALSE, 1/0.