Anaplan Analyst is a secure, generative AI assistant that leverages our rich, agentic framework to help your team gain deeper insights, accelerate decision-making, and interact using natural language.
- Modern, Intuitive UX: Ask questions and get real-time answers using natural language.
- Causal & Diagnostic Analysis: Analyst will drill down to tell you the “why” behind your metrics.
- Approved Model Write-Back: Update your forecasts and plans directly from Analyst using writeback into live Anaplan models.
To make this possible, we’ve changed how Analyst accesses your models. We’ve done away with complex configurations and scheduled data syncs and instead enabled Analyst to look directly at the underlying models connected to any enabled UX app or Anaplan application.
This gives users real-time insights using live data, pulled directly from your models, but also gives Analyst access to all data points in the model the user has access to. Users can get answers to questions using data that hasn’t already been published to UX pages.
Because Analyst reads the full model detail (modules, line items, lists, and notes) and can now write back to live plans, now is a great time to perform a thorough model review before enablement. This guide gives COE leads, Solutions Architects, Model Builders, and AI Admins a checklist to verify that your model security, role-based access, and approaches to data discoverability are properly configured, ensuring Analyst only accesses and surfaces the data each user should be seeing.
How Analyst changes things
Today, most users access model data through the UX apps built on top of it. That means a user's actual access to data depends on two things: what's been published to the UX, and the permissions set within the model itself. For example, someone with broad Role or Selective Access to a module still won't see that data if it was never added to a page. Many Page Builders use UX techniques such as filtering out specific list members, leveraging saved views, hiding specific line items, and setting page-level Manage Access rights to restrict the data their users can view. In effect, the UX layer acts as an additional filter on top of the model's real permissions.
Analyst removes the filter that the UX provides. Because it searches across the entire model (or all models connected to the enabled app) to answer a question, any data a user has access to through their Role, Selective Access, or Dynamic Cell Access (DCA) settings can surface directly in a response, whether or not that was ever intended.
As a model builder, this means thinking beyond what's exposed in UX apps and drilling into the underlying model architecture, since Analyst can read the entire model.
The key takeaway for builders
“We haven’t added this to a page” is no longer a valid mitigation. If your access controls permit it, Analyst can surface it. Treat every model and UX App enabled for Analyst as if every permitted data point is one prompt away from being shown to a user.
A note about DCA. Dynamic Cell Access is the primary tool model builders have to hide data, but it's worth seeing through the right lens: it's not true security. DCA is driver-based suppression. Rather than a structural permission like a Role, DCA hides a specific cell only if a Boolean line item evaluates that exact data point intersection and says to hide or expose that data point. It's only as reliable as the driver logic behind it. Treat it as another modeling exercise to review carefully, not a control you can simply switch on and trust. For any workflow that includes writes to the model, DCA is an important tool to help mitigate any accidental approval overrides from Analyst. Finally, DCA is an important tool, but apply it thoughtfully, as it can impact model size and performance if you don't follow best practices.
The model security review checklist
The sections below outline the necessary steps to follow before enabling Anaplan Analyst. This review should be done periodically as your models evolve over time.
Step 1: Walk through the decision tree
Use the decision tree below to assess, at a high level, whether a UX App or model is ready to have Anaplan Analyst enabled, or whether updates are needed first. If a model or app contains no sensitive data or personally identifiable information (PII), it’s ready to go. If it does, follow the tree to determine which updates may be required.
Step 2: Review your models
Work through this checklist for each model behind any app you plan to enable. These are the model-level configurations that directly determine what Analyst can surface.
Checking your models
🔲 Are Model Role permissions set appropriately? Confirm access is not defaulted to Read for all modules, lists, and versions.
🔲 Is Selective Access enabled where needed? Confirm it is applied at the appropriate levels, considering all modules with Read/Write User Role access, and applied against list-formatted line items wherever sensitive data is present in lists.
🔲 Are Dynamic Cell Access (DCA) drivers being driven by any writable line items?
🔲 Are there any import line items set with write access for any Roles, or do any of those modules include override functionality for users?
🔲 Are you using Workflow? If so, are any cell writes (Booleans, approvals, comments, etc.) driven via workflow writes? Are you using the user lists as a list-formatted line item anywhere in the model to specify recipients or approvers? Do you want to restrict them to see only their own requests or approvals?
🔲 Are you using custom user lists anywhere in the model? Is this list restricted by Selective Access?
🔲 Do all the line items currently in a Read/Write module need write access, or can some be split into a separate module? Of course, following the PLANS standards?
🔲 Check which modules are available by User Role in Contents; are you comfortable with users opening these modules directly within the modeling experience, if not, deselect any module you don’t want users accessing through Analyst links?
Checking the UX
The UX layer introduces its own filtering and visibility logic, but this has no effect on what Analyst can or can't read. Review all pages to check for UX techniques used to hide data that the model layer will reveal through Analyst.
🔲 Are Saved Views or Custom Views used to filter out sensitive line items or list members?
🔲 Are you hiding line items in your UX Cards and removing user pivoting to ensure hidden lines aren’t exposed?
🔲 Are user-based filters applied in the UX to protect data?
🔲 Are UX filters used to hide line items or list members?
🔲 Have any modules been explicitly left out of UX pages because of their sensitive nature?
🔲 Do any Pages have Manage Access restrictions applied within the UX App?
🔲 Are My Pages disabled to prevent users from accessing data?
After your review of the model and UX, update the models’ security as needed to prevent accidental exposure. If that isn’t possible, do not enable Analyst for the associated applications just yet.
Step 3: Build this into your routine
This isn’t a one-time exercise. Security reviews like this should already be part of on-going model management and are important for any production model, whether it’s accessible by Analyst or not.
- Inventory your apps and models. List every UX App enabled (or planned) for Analyst, and every model behind each app. Queries in Analyst follow the model, not what’s been added to a page.
- Run the decision tree per model. A single app can draw on more than one model; work through each one on its own.
- Work through the checklists with people who know the design. The COE leads, Model builders, and the Page builders for each app and model are best suited to confirm Roles, Selective Access, DCA, Saved Views, page-level settings, etc.
- Set a regular cadence. Pick an interval that fits your team, quarterly or aligned to your release cycle, and repeat this review for models in production.
- Revisit after changes. Any new module, workflow write-back, or major structural change should trigger another security check, in addition to your regular cadence.
Design considerations
- Analyst focuses on the model(s) that make up an app, not the UX pages a user has used in the past. For true user access testing, review at the model level, even if your prior testing focused mainly on the UX.
- Roles, Selective Access, and DCA work together as layered controls. A gap in one layer isn't automatically covered by the others; validate each on its own. Understand the scope and limitations of each.
- UX-level “view settings” (Saved Views, hidden line items, page-level access, etc.) shape the page experience, but they don’t replace model-level security. The underlying Role and Selective Access are ultimately what govern what Analyst can read.
- Add this review to your existing model management routine. Make it a regular part of release testing or access reviews. Don't treat this as a separate, one-off task.
While Analyst attempts to understand the context and intent of the model architecture, model security can reduce, but may not fully eliminate, data being shared with users that you did not intend. For example, some line items require read access simply to support a calculation string, and others need write access for workflow, imports, or actions. If your review finds line items that can't be restricted and contain data that would introduce confusion, inaccuracy, or sensitivity if surfaced, you may want to hold off on enabling Analyst for the related apps.
Conclusion
Getting a model ready for Anaplan Analyst is the same work that keeps any production model secure: confirming that Roles, Selective Access, and Dynamic Cell Access reflect exactly the data each user is meant to see. Because Analyst reads across the full model, the model layer is now the boundary that matters. Run the decision tree and checklists above for each app and model you plan to enable; make it a recurring check rather than a one-off, and you’ll be in a strong position to activate Analyst with confidence.
Contributors: Rob Marshall, Theresa Reid, Jason Blinn, Dave Waller, Ruth Juni, Adam Trainer, Elizabeth Schera.
