Author: Sripriya Rao is a Tech Lead at Prudential Financial and an Anaplan Solution Architect.
How to choose safe, predictable behavior for file and model-to-model imports
Quick takeaway
- Use “Only update imported cells” for delta/partial sources and most automated runs.
- Use “Clear target prior to import” only when the source is authoritative for the slice you’re refreshing.
- If you clear, scope it per dimension (especially Time) don’t assume it wipes the whole module.
- “Import succeeded” isn’t validation—add basic checks (totals/row counts/reasonableness) for production loads.
Who this is for: Model builders and integration developers configuring import actions/processes who want predictable outcomes — and fewer “import succeeded, numbers are wrong” surprises.
Overview
Imports fail in two common ways: they wipe too much (because clearing was broader than expected) or they don’t change enough (because update-only can’t remove data). This post walks through a simple decision, then shows how to scope clearing and mapping so your loads stay safe — especially for file-based feeds and Time.
- In scope: module imports (file and model-to-model), clearing behavior, per-dimension clear scope, blank handling, mapping pitfalls, Time mapping, and list-import risk patterns.
- Out of scope: detailed API code, file chunking strategies, and end-to-end integration architecture (these vary by toolchain).
Definitions used in this guide
- Target slice: the set of cells an import can affect, defined by mapped dimensions (including any fixed mappings) and the clearing selections.
- Scoped refresh: clearing and reloading only a defined portion of a module (for example, Actual + current month + mapped cost centers).
- Partial feed (delta feed): a source that contains only changes, not the full dataset for the target slice.
- Blank: an empty source cell. Depending on import settings, blanks may be ignored or may contribute to clearing (within scope).
- Mapped items in source / All mapped items / All items: per-dimension options that control how broadly data is cleared for that dimension (explained in Section 2).
Prerequisites
- You can access and edit the import action (or integration process) in the target model.
- You know whether the source is a full refresh or a delta feed for the intended target slice.
- You have confirmed which dimensions are mapped (including fixed mappings) and how Time is mapped.
- For automated loads: you have monitoring/validation in place (for example, row counts, totals, or reasonableness checks).
How to read this post
This post is decision-first: pick the right behavior (clear vs update-only), then verify the clearing scope per dimension and mapping (especially Time).
- Start with Section 1 if you’re deciding between clear vs update-only.
- Jump to Section 2 if you already chose clear target and need to scope it correctly.
- Use Sections 3–5 to sanity-check mapping (especially Time) and list-import risk.
1) Decide intent (60-second decision)
Figure 1. Decision guide — choose the behavior that matches source completeness and risk.
Question | If Yes | If No |
|---|
Does the source represent the entire truth for the target slice? | Use Clear target prior to import (scoped) | Use Only update imported cells |
Should blanks explicitly remove existing values? | Use Clear target | Use Only update |
Is this a recurring, automated load? | Prefer Only update | Clear target may be acceptable (with controls) |
2) Choose behavior: Clear target vs only update imported cells
Figure 2. Illustrative import action options — clear target versus only update imported cells. Please note that this is an illustrated mock-up, not a screenshot of the Anaplan platform.
Side-by-side comparison
Aspect | Clear target prior to import | Only update imported cells |
|---|
Mental model | Wipe → then write | Compare → update |
Best for | Full or scoped refresh | Incremental / delta updates |
What happens first | Target values are cleared (per scope) | No clearing step |
Handling blanks | Blanks can clear values (within scope) | Blanks ignored |
Items not in source | Untouched if scope is limited | Always untouched |
Operational risk | Higher | Lower |
Expanded pros and cons (decision-grade)
Dimension | Clear target prior to import | Only update imported cells |
|---|
Core behavior | Clears target values first, then loads new data | Updates only matching target cells |
Intended use | Replacement / refresh | Incremental updates |
Removal of obsolete data | Yes | No |
Sensitivity to partial feeds | Risky | Safe |
Automation friendliness | Requires strong guarantees | Preferred |
Recoverability | Lower | Higher |
Data determinism | High | Medium |
Common failure mode | “Why was this wiped?” | “Why didn’t this change?” |
How this choice differs by import type
Import type | Recommended default | Why |
|---|
File import | Depends on feed quality | Files are often partial, manual, or corrected |
Model‑to‑model import | Often Clear target (scoped) | Source model is usually authoritative for that slice |
Anapedia references: Mapping rules apply to both file and model-to-model imports.
Example use cases by import type
File imports
- Manual upload of corrected data
- Daily delta feed from an upstream system
Recommendation: Prefer Only update imported cells unless the file is explicitly complete.
Model to model imports
- Data Hub → spoke model actuals
- Standardized calculation outputs
Recommendation: Clear target prior to import is often appropriate, with strict scoping.
Why they behave differently
- Clear target prior to import follows a wipe → then write sequence. Clearing occurs before loading.
- Only update imported cells follows a compare → update approach. Only non blank source values update targets.
Common misuses and how to avoid them
Misuse #1: Using Clear target with a partial feed
Symptom: Data disappears even though it is not present in the source file.
Why this happens: Clear target assumes the source represents the full truth for the configured scope.
More likely with:
- File imports
- Manual uploads
- Feeds missing unchanged rows
Avoid this by using only update imported cells for file based or delta loads.
Restricting clear scope to Mapped items in source.
Note: If the source is not complete, do not use Clear target.
Anapedia reference: Clear target cells prior to module imports
Misuse #2: Assuming Clear target wipes the entire module
Symptom: Nothing cleared — or far too much cleared.
Why this happens: Clear target is enabled globally but executed per dimension.
Avoid this by:
- Explicitly configuring each dimension tab
- Treating Time as a separate clearing decision
Note: No dimension configuration = no clear.
Anapedia reference: Clear target cells prior to module imports (scope options).
Misuse #3: Expecting Only update imported cells to remove data
Symptom: Old values remain even though they “should be gone”.
Why this happens: Update only imports never remove data.
Avoid this by:
- Using Clear target when removal is required
- Or splitting the process into clear + reload
Note: Update only preserves data by design.
Anapedia reference: Map items / columns in an import.
Misuse #4: Using Clear target in automated integrations
Symptom: The job completes successfully, but production data is incorrect.
Why this happens: Automation amplifies upstream failures.
Risk comparison:
- File imports: Very high risk
- Model to model imports: Moderate, if contracts are clear
Avoid this by:
- Preferring update only in automation
- Adding validation checks
- Limiting Clear target to controlled runs
Anapedia reference: Clear target cells prior to module imports.
3) Scope the clear (it’s configured per dimension)
Figure 3. Illustrative dimension-level clear scope — clear target is configured per dimension. Please note that this is an illustrated mock-up, not a screenshot of the Anaplan platform.
What controls clearing
Dimension type | Why it matters |
|---|
List dimensions | Controls which items are cleared |
Time | Controls which periods are wiped |
This applies equally to file imports and model to model imports.
Non-Time clear options
Option | Meaning | Typical use |
|---|
Mapped items in source | Clears only items present | Safer, incremental |
All mapped items | Clears defined targets | Controlled refresh |
All items | Clears everything | Rare, high‑risk |
Anapedia reference: Dimension-level clearing options.
Clear target cells prior to module imports.
Scoped refresh example (model-to-model)
Data Hub → Actuals model
Dimension | Setting |
|---|
Cost Center | All mapped items |
Time | Current month |
Version | Actual |
- Deterministic refresh
- No historical overwrite
4) Mapping checks (file vs model-to-model)
Mapping priorities
Area | File imports | Model‑to‑model imports |
|---|
List identifiers | Prefer codes | Usually enforced |
Version mapping | Explicit | Often fixed |
Time mapping | High‑risk area | Usually aligned |
Line‑item match | Prone to mismatch | Stable via saved views |
When an import succeeds but the data is wrong: common root causes
Import type | Common cause |
|---|
File import | Name/code mismatch; wrong Time mapping |
Model‑to‑model | Wrong saved view; unexpected dimensionality |
Best practice: Validate mapping assumptions (especially Time and list identifiers) — do not rely on “Import succeeded” as a data quality check.
Anapedia reference: Mapping fundamentals (map items and columns).
5) Time mapping (where file imports go wrong)
Figure 4. Illustrative Time mapping view — validate source format and target period mapping. Please note that this is an illustrated mock-up, not a screenshot of the Anaplan platform.
Source format | Recommended mapping |
|---|
YYYY‑MM‑DD | Dates |
YYYY‑MM | Periods |
MMM YY | Match names (exact match only) |
Key insights
- Time mapping errors occur far more often in file imports
- Model to model imports usually inherit consistent time labels
Anapedia reference: Time mapping details. Map the timescale in a module import.
6) List imports (higher risk with file-based ingestion)
Patterns and risk
Pattern | File imports | Model‑to‑model |
|---|
Append only | Safe | Safe |
Update properties | Safe | Safe |
Clear & reload | High risk | Medium risk |
Clear-and-reload risk (file imports)
Repeated clear-and-reload activity on ingestion lists can exhaust internal list indices over time, even when individual jobs report success.
Avoid by:
- Using append/update patterns
- Avoiding daily full reloads
- Resetting index only with full understanding
Anapedia reference: List imports and index reset.
7) Operational hygiene (especially for automation)
Figure 5. Illustrative import run log — successful execution still needs business validation. Please note that this is an illustrated mock-up, not a screenshot of the Anaplan platform.
Practice | Why it matters |
|---|
Separate file vs model‑to‑model processes | Different risk profiles |
Name actions clearly | Easier auditing |
Tie imports to processes | Better troubleshooting |
Validate automated runs | Job success ≠ data correctness |
Anapedia reference: File preparation for stable imports.
Prepare your import.
Final checklist (before production)
- Is the source file based or model based?
- Is it complete or partial?
- Should blanks remove data?
- Is clearing scoped correctly?
- Is Time mapped safely?
- Is this automated?
Golden rule
If the source does not explicitly represent the full truth for the target slice, do not use Clear target prior to import — especially for file imports.
Discussion
What’s the most common import failure mode you see in practice (and which setting caused it)? If you can, share whether it was file vs model-to-model, full refresh vs delta, and whether the run was automated.
- Clear target used with a partial/delta file feed
- Time mapping that shifted values into the wrong period
- Automation runs that completed “successfully” but produced incorrect totals
