-
How I Built It: Period-driven variance reporting
Author: Nizar Cherkaoui is a Certified Master Anaplanner and EPM Manager and Solution Architect at VISEO.
In this How I Built It video, I demonstrate how to design period-driven variance reporting in Anaplan when comparison logic is unknown upfront and flexibility is required.
Instead of embedding period choices directly into calculations that often rely on user-dimensioned logic for concurrency, the model is built on multi-dimensional modules that enable a fully context-driven user experience. Users select a base period and a current period, and the model dynamically aligns volumes, prices, and revenues to those selections, without duplicating modules or rewriting formulas.
The main advantage of this approach is scalability and performance. By clearly externalizing context selection through multi-dimensionality and mapping, the design stays stable, explainable, and easy to maintain as business evolve.
https://play.vidyard.com/FtkP6in9x8oyT1cAbwvFdF
Questions? Leave a comment!
-
How I Built It: Refreshing current date in an Anaplan model using Cloudworks
Author: Sai Bandaru is a Certified Master Anaplanner with six years of experience architecting Anaplan models.
Hello Anaplanners! In today's fast-paced business environment, having accurate and up-to-date information is crucial for making informed decisions. In this ‘How I Built It’ tutorial, I'll explore a practical and efficient way to refresh the current date in your Anaplan model using Cloudworks.
How to refresh the current date with Cloudworks
Follow along in the video as we walk through the step-by-step process of using Cloudworks to refresh the current date in your Anaplan model. Whether you're a seasoned Anaplan user or just getting started, this tutorial will provide valuable insights into streamlining your workflow and keeping your models dynamically linked to real-time information.
Key benefits
* Real-time decision making: keeping the current date updated ensures that your models reflect the most recent business context, allowing for more accurate and timely decision-making.
* Automation for efficiency: Cloudworks simplifies the process, automating the refresh of the current date, saving you time and reducing manual effort.
* Improved model accuracy: by regularly updating the current date, you can enhance the accuracy of your forecasts, budgets, and plans, leading to more reliable insights.
https://play.vidyard.com/4nJKBPtUY38r3kwVVHKrS3
Conclusion
In conclusion, mastering the art of refreshing the current date in your Anaplan model with Cloudworks is a valuable skill that can significantly impact the effectiveness of your planning and analysis processes.
Questions? Leave a comment!
……….
All the 'How I Built It' tutorials can be found here.
-
Evolving business requirements over time: Retroactive changes and effective dating
Author: Marc Weinzimmer, Certified Master Anaplanner and Senior Project Manager at Alpha.
The day a new Anaplan model goes live is always exciting. The model is clean, fast, and aligned with current business needs; admins are trained, users are engaged, and everything appears to be running smoothly. However, as time passes, business requirements inevitably evolve. How a model is designed to handle these changes will directly affect user trust, historical accuracy, and the long-term effort required to maintain and enhance the solution.
When time and structure change
One of the first major tests a model faces occurs when time moves forward. Rolling the calendar ahead often requires adding new years or removing old ones, and Anaplan handles this type of change well through its dynamic time settings. More challenging, however, are structural changes such as organizational or regional reorganizations. While hierarchy relationships can be easily updated, doing so raises an important question: should historical data reflect the new structure, or should it preserve how the organization looked at the time? This decision fundamentally shapes how the model must be designed.
Retroactive changes vs. effective dating
If a change should apply to both current and historical data, it is considered retroactive. Retroactive changes simplify modeling but permanently alter historical context. When historical relationships must be preserved, effective dating becomes necessary. Effective dating introduces a time component to attributes like region assignments, manager relationships, or pricing, allowing multiple versions of a relationship to exist while ensuring only the correct one applies at any given point in time. Although effective dating provides accuracy and flexibility, it increases model complexity and can impact usability due to additional lists and similar-looking records.
Models as living systems
Over the years, models continue to evolve as new functionality is added, user experiences shift, and business processes grow more complex. What began as a simple solution often becomes a deeply embedded system that supports critical planning and reporting. At some point, teams must evaluate whether ongoing enhancements are sustainable or if a model refresh is needed. This decision involves balancing improved design and performance against the cost and risk of rebuilding, while also considering how much historical data truly needs to remain active in the model.
Conclusion
Successful Anaplan models are designed with change in mind. Understanding when to apply retroactive changes, when to use effective dating, and how to plan for a model’s lifecycle can mean the difference between a model that scales gracefully and one that becomes difficult to manage. By making thoughtful design decisions early and revisiting them as the organization evolves, model builders can ensure their solutions remain accurate, performant, and trusted over time.
…………..
More from Marc: A practical guide: Customer tenant split
-
Do scheduled CloudWorks actions run in parallel or sequentially?
If we schedule two CloudWorks actions to start at the same time, using the same source model but different saved views, and updates two different target models, will they run in parallel or sequentially (with one finishing before the other starts)?
-
How I Built It: Sensitivity analysis
Author: Casey Pham is a Certified Master Anaplanner and Director of FP&A Systems at Yext.
In this ‘How I Built It’ video I'll show how I built a model and process to run a sensitivity analysis. Tens or hundreds of scenarios without overloading the model with too many scenario list items and manually updating driver inputs over and over.
What is a sensitivity analysis?
A sensitivity analysis is similar to a what-if analysis to see how changes in one variable affects the outcome in another. It helps to understand risk, identify key drivers, and insulate the impact of different factors. In this simple example, we see how different bookings forecasts (columns) and different expense drivers (rows) will affect net income and net margin after it runs them through a revenue model and P&L statement.
The 'How I Built It' video is below, but first here are the steps I took.
Steps and components
Step 1
Set up a list for each driver with the number of scenarios you want for each one. The list item code must be numerical and sequential. Create a subset for the active scenario (will explain later on)
.
Add a corresponding module to input the drivers in for each scenario.
Step 2
Create an index list, a numerical list. At a minimum it should be the number of scenario combinations you have. e.g. 5 bookings and 5 expense scenarios equals 25 combinations
Create a module that will assign a number to each scenario combination, via rank function, then finditem it to the index list.
Step 3
Create a control module that will be used in the integration process to know which combination of scenarios to calculate.
Step 4
Set up actions and combine them into a process:
* Import scenario drivers into their applicable model.
* In each scenario list, clear the active subset and mark the current active scenario.
* Export the model results into the a staging table that only has the active subset of scenarios.
* Export the results from the staging table to the sensitivity table.
* Increment the scenario number parameter to the next one.
Repeat from step 1 as many times as the number of scenario combinations you have. Alternatively, use Anaplan Connect and a script that you can set the number of times to repeat the same process.
'How I Built It' video
https://play.vidyard.com/gd5NCnKxPgt6koRDvzWnH8
Questions? Leave a comment!
……………
See all 'How I Built It' tutorials here.
-
How to maintain complex Anaplan environments — Part 2: Technical foundations for scale
Author: Piotr Weremczuk is a Certified Master Anaplanner and FinSys Application Specialist at EQT.
In the first part of this two-part article, I explored the non-technical foundations of maintaining complex Anaplan environments: leadership, governance, accountability, and the importance of building the right team. All of that came from my ten years of working with Anaplan.
Now, in this second part, I want to shift focus to the technical side: the tools, practices, and architectural decisions that make day-to-day maintenance smoother, more predictable, and far more scalable.
If the first part was about laying a stable foundation, this part is about the practical mechanics that solution architects and model builders rely on every day. These are the elements that turn a theoretically strong setup into a reliably functioning ecosystem.
Architecture starts early, and it starts from above
Even on the technical front, everything begins surprisingly early.
In Part 1, I wrote about the importance of having a leader with vision — someone who pushes the organization to evolve and sees beyond the first model. The same applies technically.
A skilled solution architect (or even better, a “Master Architect”), must look at the environment from above, not from within. Someone needs to own the blueprint: the data landscape, the model interconnections, the integration patterns, and the tools wrapped around Anaplan.
Personally, I’ve always found clarity through drawing.
Whether it's Lucidchart, Draw.io, or anything that lets you sketch system architecture, having a visual representation of your full ecosystem is invaluable. When you lay it all out — the current structure, the desired future state, and everything in between — gaps reveal themselves. Dependencies become clearer. Priorities almost arrange themselves.
My thinking shifted dramatically when I was first exposed to architectural frameworks, like TOGAF for example. You don’t need to become an enterprise architect, but a basic understanding of these methodologies teaches you to think differently: in layers, in transitions, in future states.
And in a complex Anaplan landscape, that “bird’s-eye view” is what keeps everything coherent and ensures the platform adheres to connected planning principles.
Automation: The great multiplier
If there is one technical topic I would emphasize above all else, it is automation.
Today’s Anaplan ecosystem is rich with tools that simplify orchestration, but it wasn’t always that way. I still remember the days before CloudWorks, before ADO integrations, even before ALM. We spent countless hours running manual imports, deploying changes manually, and tracking errors after the fact instead of as they happened.
Thankfully, those days are behind us.
ALM: the non-negotiable
If you follow the recommended Dev → Test → Prod setup, ALM is already at the heart of your process. If it isn’t — that’s your homework. Proper ALM structures are what make controlled development possible, especially in large environments with multiple parallel workstreams.
CloudWorks: simple, native
CloudWorks has become one of those indispensable tools even for organizations that don’t use AWS, Azure, or GCP.
Its value is in its simplicity: native scheduling, easy configuration, built-in monitoring, and the ability to push alerts through email or even a Slack channel. It immediately adds value and effortlessly enables automation in Anaplan.
External ETLs: essential for scale
Then there are the heavy-duty engines: native ADO or external ETLs; whatever the organization already owns.
A proper ETL layer is not a luxury; it is a necessity.
Yes, you can survive with Anaplan Connect or manual imports. But you will never scale with them.
Most delays and failures I have seen in Anaplan projects were rooted in data issues. A robust ETL not only moves data; it monitors, cleans, transforms, and audits it. That reliability is what allows Anaplan environments to grow without collapsing under their own weight.
Automation beyond imports
One recurring challenge I’ve encountered is giving business users the ability to trigger external processes without relying on IT each time. Exposing a simple webhook on a dashboard can fundamentally change how teams interact with the wider architecture. Suddenly, users can launch complex, multi-system workflows with a single click. Once this foundation is in place, integrations become far more accessible, connecting Anaplan to tools like Workato, for example, turns into a straightforward exercise. And from there, the automation possibilities across your tech stack expand rapidly.
When you integrate Anaplan this way, it stops being a standalone application and becomes the orchestrating center of your organization’s planning architecture.
Scaling access management through automation
As environments grow, so does the complexity of user management.
Hundreds, or even thousands, of users across multiple workspaces quickly turn into a labyrinth of manual checks, outdated permissions, and forgotten roles.
Automation is, once again, the solution.
Using the SCIM API to synchronize users, or creating a custom tool that consolidates exported user lists, makes license oversight far more manageable. Automated reporting of roles, workspace activity, and last login dates is essential.
Without these controls, organizations inevitably pay for unnecessary licenses or maintain old access assignments long after the users have stopped participating in the processes.
A well-designed access management automation not only protects the budget, it safeguards security, compliance, and operational clarity.
Best practices: Small habits with massive long-term impact
This chapter could easily be its own standalone guide. Best practices are often framed as something for junior Anaplanners, but the truth is that they protect senior teams just as much. They are the invisible scaffolding that keeps models maintainable years after they are built.
Clean builds, consistent naming conventions, and a logical DISCO structure all contribute to clarity. But there is something even more important: discipline.
Discipline to remove testing line items when you’re done.
Discipline to delete unused imports.
Discipline to keep your structure understandable not just today, but years from now.
Over time I’ve collected small tricks that may not appear in official documentation but make a huge difference in practice:
* Creating dummy actions to act as separators in the Actions tab
* Naming data sources to reflect actual integration names
* Using notes to document unexpected logic or hidden dependencies
* Marking certain backend elements (DCA, conditional formatting, filters, deletion logic) with subtle emoji identifiers
(Despite Anaplan’s caution about emojis, I’ve never found them problematic for backend work.)
These are small touches, but across dozens of models, they create an ecosystem that is intuitive, self-explanatory, and easy for new team members to adopt. And for leaders, enforcing these practices is one of the simplest ways to reduce long-term maintenance risks.
Bringing it all together
There is no single trick that magically makes an Anaplan environment easy to maintain. Instead, it is a combination of structural thinking, strategic automation, disciplined development, and architectural clarity.
The list in this article is not exhaustive — Anaplan evolves too quickly for any list to stay complete for long — but these are the elements I’ve consistently found to have the greatest impact.
And they work.
Today, together with my colleague, we maintain an environment with seven workspaces, more than ten use cases, dozens of active models, and hundreds of users. Not only do we keep it stable — we have enough capacity to expand into new processes at the same time.
That is the power of thoughtful setup, automation, and discipline.
Thank you for reading.
And if you missed it, Part 1 explores the organizational and human aspects of maintaining complex Anaplan environments; the foundations that make all of this technical work truly effective.
Questions or comments?
-
How I Built It: Number format converter (thousands and millions)
Hello Anaplanner Community! I’m excited to participate in another ‘How I Built It’ video with a Number Format Converter (thousands and millions) tutorial.
This video walks you through how to dynamically update UX grid number formats on all tables and charts. This enables users to have different number formats enabled for each line item.
Key features:
* Users can choose which line items they would like to see numbers in thousands or millions.
* Allow users to easily see larger values in small Anaplan UX grids.
* You can design for each line item you would like to have this for.
* Check out my idea in the Idea Exchange and upvote: Number scale line item format.
https://play.vidyard.com/dDXJDFqms1HSkfNC2aG7Jc
I have another ‘How I Built It’ tutorial on dynamic month, quarter, and year filters here.
All the 'How I Built It' tutorials can be found here.
…….About the Author: Arjun Gandhi is a Co-Founder and Certified Master Anaplanner at Tekplanit and has been in the Anaplan ecosystem for 8+ years. He has deployed hundreds of applications across 16+ industries for finance, supply chain, and sales use cases.
-
Interviewing and onboarding Anaplanners
Author: Andrew Barnett is a Certified Master Anaplanner and Vice President at PJT Partners.
Having worked at several firms in the Anaplan ecosystem, both on the partner side and as a customer, I’ve seen firsthand how critical it is to hire and develop the right Anaplan talent. Bringing an experienced Anaplanner onto your team and successfully onboarding new model builders are crucial steps in growing an Anaplan capability. In this post, I’ll share personal insights on what I’ve seen work (and not) in interviewing experienced Anaplanners and in training up new ones from scratch.
When interviewing candidates with Anaplan experience, I focus on three key areas: technical skills, relevant experience, and personality/culture fit. Covering all three gives a more accurate view of the candidate’s suitability for the role and the team.
Technical assessment: In my experience, technical interviews for Anaplan roles usually take one of three forms: a take-home modeling exercise, a knowledge test (written or verbal Q&A), or a live problem-solving session. Each has pros and cons, but the live exercise tends to be the most revealing.
Experience: Beyond technical ability, I ask about the candidate’s Anaplan project experience. What types of models have they built, and in what business areas? What was their role in those projects? This helps me gauge depth of practical knowledge and whether their background aligns with our needs.
Personality/team fit: Anaplan modeling is collaborative — model builders work closely with end users, stakeholders, and other Anaplanners. I look for strong communication skills, a problem-solving mindset, and a constructive, low-ego approach. A few targeted behavioral questions often provide a clear signal on how they’ll show up day-to-day.
Of the technical assessment methods listed above, the live problem-solving exercise has given me the best insight into a candidate’s capabilities. There’s nothing like watching someone tackle an Anaplan problem in real time to reveal their true skill level.
For this, I’ll prepare a simplified real-world scenario and ask the candidate to troubleshoot it with me live. As they work through it, I observe how they navigate the model, isolate the issue, and explain the reasoning behind each step.
This approach shows how a candidate thinks on their feet. Strong candidates will methodically identify assumptions, test hypotheses quickly, and keep the end-user outcome in mind. I’ve seen highly certified candidates struggle in a hands-on test, while others with fewer credentials excel, reinforcing my belief that performance in a live exercise matters more than badges alone. If you can include a live exercise in your hiring process, I highly recommend it; it’s the closest proxy for real work you’ll find in an interview.
Skilled Anaplanners are in high demand, so many teams will need to grow their own talent. Whether you’re upskilling an internal employee or hiring someone new to Anaplan, a structured onboarding program is critical. The best approaches I’ve seen combine Anaplan’s learning resources with realistic internal simulations.
I’ve seen two firms handle it particularly well:
* “Basics + Project” approach (Akili): Early in my career, before today’s structured training ecosystem existed, new model builders started with foundational Anaplan training to cover the essentials followed by a sample project. In this sample project, new hires received data files and business requirements that resembled a client use case and were asked to build a simple model to meet those needs. After a short build period, they presented their solution to the team, walking through why they made the design decisions they did. This was an incredibly effective way to accelerate learning and build confidence. It also gave managers a practical view of who was ready for more complex work and who needed additional support.
* Comprehensive blended program (Allitix): Years later, I saw an even stronger approach that intentionally fused Anaplan’s structured learning path with internal simulations. The agenda included the formal Anaplan certification track alongside other important Anaplan courses, followed by a sample project. What I appreciated most was that this program wasn’t just for entry-level model builders. It also included more advanced sample projects for experienced hires and people looking to move into more senior roles. That type of tiered development is rare, and it’s a powerful way to create a consistent bar for progression while keeping high performers engaged.
The common thread between these successful programs is the marriage of theory and practice. Formal training gives you the vocabulary, patterns, and best practices. Hands-on simulation make you apply that knowledge.
This mirrors how people learn to code: the fastest growth happens when you build something real that matters. The same is true in Anaplan. You can understand model design principles conceptually, but you only internalize them when you wrestle with real data, tradeoffs, and stakeholder expectations.
Investing in thoughtful interviewing and onboarding for Anaplanners pays off. When hiring experienced talent, go beyond standard Q&A and check how they solve problems in the moment. When building new talent, pair Anaplan’s learning resources with structured, real-world simulations that reflect the work your team actually does.
In my experience, teams that get these two processes right build stronger models, earn trust faster, and scale their Anaplan capabilities with far less friction.
Good luck and happy planning!
.png){kind=icon}
