Problem / Context
Within a single Anaplan model, Hyperblock technology tracks dependencies between line items automatically. No equivalent capability exists for tracking dependencies between models - specifically, for the data imports that move data from one model (or external source) into another, or even imports within a model.
Today, mapping these cross-model data flows is a laborious manual process. A model builder must visually inspect each import action one by one, navigate into saved views to read filter expressions, identify which line items drive those filters, and separately check CloudWorks to find which integrations invoke those imports. For tenants with dozens of models and hundreds of imports, a complete dependency map can take days and goes stale every time an integration changes.
The following information is necessary to automate this work, but no single API or export surface provides it all:
1. Import data source identity
For each import action in a model, we need to know: is the source a flat file, a list, a module/saved view, or another model? If it is a saved view, which model and which module does it come from?
2. Saved view filter and dimension details
When a saved view is the import source, we need the complete filter expressions defined on that view - including which line items are used to compute each filter condition - and the show/hide settings that limit which dimensions and members are exposed.
3. Source model re-mapping
Workspace administrators use the Source Models pane to re-map model-to-model imports from one source model to another (e.g. for ALM model setup, during an environment migration or tenant, reorganization). These mappings can be exported as Grid - Source Models.csv, which is accessible via Anaplan Integration API.
4. CloudWorks integration linkage
For imports that read from a cloud file, we need to know which CloudWorks integrations invoke that import (or a process that contains it) and which cloud file each integration reads from.
Partial workarounds that exist today:
Anaplan's OEG team has published a Best Practices article, Creating a Data Integration Schema for your Models, that documents the manual steps required to compile this information. It explicitly notes: "there are no APIs available today to get this information." The article describes a multi-step process of copying data from the Import Data Sources list, Imports list, Actions list, and Source Models pane in each model, then assembling it externally. For large tenants, this is impractical to maintain.
Beyond that manual approach:
- The Grid - Actions.csv export surfaces some action-level metadata, but does not include data source details for imports.
- The Anaplan Integration API can return source information for an import if a process is first constructed that contains that import action. This is a cumbersome prerequisite and not a supported workflow for dependency discovery.
- The CloudWorks API exposes integration configurations but requires separate calls per integration and has no built-in linkage back to the model-side import action contained within a process invoked by CloudWorks.
- Saved view filter expressions and dimension show/hide settings are not exposed by any current API or export.
There is no supported, automated path to produce a complete cross-model dependency map without combining several brittle workarounds.
Frequency of Impact
Every time a model builder needs to understand, document, or validate cross-model data flows - which arises during model migrations, ALM promotions, integration troubleshooting, onboarding new team members, or tenant governance reviews. For organisations with large multi-model architectures, this can be a weekly or monthly effort.
Who Is Impacted
Integration experts and model builders responsible for multi-model Anaplan implementations. Particularly acute for enterprise tenants with many connected models, where manually tracing integration dependencies is a significant ongoing overhead.
Ideal Solution
Expose the following data through the Anaplan Integration API (or a new dedicated Dependency/Metadata API endpoint), so tooling can be built to automate cross-model dependency mapping:
- Import source details per action - for each import in a model: source type (file, list, saved view, model), source model ID and name (if applicable), source module ID and name (if applicable), source saved view ID and name (if applicable).
- Saved view metadata - for a given saved view: the filter expressions applied (including the line items referenced in each filter condition) and the dimension show/hide configuration (which dimensions are shown, which members are included/excluded).
- Source model re-mapping - the contents of the Source Models pane (currently exportable only as Grid - Source Models.csv) exposed via API, so the current source model mapping for each model-to-model import can be retrieved programmatically without a manual export step.
- Cloudworks-to-import linkage - for each Cloudworks integration: the model actions or processes it invokes, the cloud file(s) it reads from, and the schedule or trigger that drives it. Ideally, this is navigable in both directions (given an import, find the processes and integrations that use it; given an integration, find the processes and imports it feeds).
A complete implementation would allow a script or tool to walk the full dependency chain: from a Cloudworks cloud file, through the integration, to the process, to the import action; or the other direction from the import, to the saved view, to the source module and its filter line items and dimension show/hide settings - entirely via API, without manual inspection in the Anaplan UI.
Related existing Idea Exchange posting: More information about imports in transactional API (Status: New) - asks for import data source ID, source model ID, and target object mapping details via the API. Ourask extends that in three additional directions: saved view filter and dimension metadata, Source Models pane access via API, and Cloudworks-to-import linkage.
