-
How I Built It: Process logging
Author: Karim Bhaidani is a Certified Master Anaplanner & Transformation Director at Spaulding Ridge.
In this 'How I Built It' video, I demonstrate how to build Process Logging in Anaplan to enable non-workspace admins to view a summary of the most recent hour and date any process ran within the model on a front end dashboard.
By using templates and schedules within Anaplan Workflow, the current date and time are automatically kept up to date in the model. These can be incorporated into a sequence of actions for each process, enabling automatic capture of a timestamp whenever a process is executed. The setup for process logging is simple and does not require advanced model architecture expertise.
This approach primarily improves overall visibility into process execution times for all users. End users can easily view when any process last ran directly from a front end dashboard, eliminating the need to contact a workspace admin to understand when an integration was loaded or when a user ran a specific process.
https://play.vidyard.com/Jtf1pG3TBzAWmfQthZzqsL
Questions? Leave a comment!
View all 'How I Built It' videos here.
-
How I Built It: ADO and Snowflake data integration
Author: Andre Lie is a Certified Master Anaplanner and Manager at Alpha Alternatives.
In this ‘How I Built It’ video, I demonstrate an end-to-end bidirectional integration between Anaplan Data Orchestrator (ADO) and Snowflake. The integration highlights how ADO acts as a centralized orchestration layer that manages and automates the flow of data between Anaplan models and Snowflake.
In this setup, I used a Snowflake database to simulate a sales planning environment. On the ADO side, I configured a connection to Snowflake, created datasets, transformation views, links for importing data and metadata into an Anaplan model, and a pipeline for exporting Anaplan data to Snowflake.
Key benefits of this bidirectional integration include:
* Support for closed-loop planning by feeding actuals and operational data into Anaplan, while publishing forecasts and planning outputs back to Snowflake
* Improved data consistency between planning and operational systems
* Centralized orchestration without relying on custom scripts or external ETL tools
* Automated inbound and outbound data integration
This demo shows how ADO and Snowflake can be leveraged to build automated and scalable data integration foundation for enterprise planning.
https://play.vidyard.com/eMRB9sY182tBdZunBSHPsR
Questions? Leave a comment!
……………
View all 'How I Built It' videos here.
-
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: Unlink revision tags
Author: Junqi Xue is a Certified Master Anaplanner and consultant at valantic.
When working across multiple models in ALM, it's common to encounter structural changes and revision tags that track updates. These revision tags are critical for synchronizing changes between production and development environments. Not all structural changes are saved immediately — they might linger in the system as unsaved changes, or you could also understand them as unsaved revision tags, creating problems.
Sometimes, unintended structural changes or poorly managed revisions lead to disruptions that break the sync between models, resulting in errors. A typical example of this is when less experienced administrators or developers mistakenly take the production model out of deployed status and make direct changes. This creates a significant challenge in bringing the production model back into sync with the development model, often leading to frustration and delays in projects.
Another common scenario arises when users unknowingly lose data after syncing revision tags. This usually happens due to a lack of understanding of how the syncing logic impacts their existing data. If there are no saved archives available, retrieving the pre-sync data can seem almost impossible, because you can’t simply revert to a history before a sync in the safe deployed mode.
The tool here to help is: Restore the PROD model with selective use of "Unlink revisions created after this restore point". What it does is it clears the structural changes and revision tags between restore point and the current point. If used properly, it can make the model back in sync.
Use case 1: To restore broken links
* Put the out-of-sync prod model back to standard mode. Optionally, put it also offline, and communicate with the user groups to prevent from unwanted touches in the model when we are doing these delicate changes.
* Go to history, find the ID before any manual changes are done.
* Restore, and tick the boolean "Unlink revisions created after this restore point".
* Structural changes are now out of the model. Prod model is back in sync with DEV. Continue modeling in DEV and sync to PROD.
Use case 2: To copy the (old) prod model to retrieve (lost) data
The best way is still of course prevent this from happening, by doing copy and archive before large/critical deployments, if not all deployments.
This is the case where I started researching the function properly.
As we all know, copying a model will create an automatic revision tag, making the model incompatible. We want to avoid that.
With the unlink function, we could clear the revision tags, so it should no longer be a problem for us.
The steps can be:
* As usual, change the mode of the production model from deployed to standard, and offline. Communicate with the users team if necessary, to prevent any unwanted touches in the model when we are doing the surgery.
* Roll production model back to the history ID to the desired status with “unlink revision created after this restore point” UN-flagged. Otherwise when we later roll the model back to current status, the revision tags saving the structural changes are gone. It will be similar to the status when the admin wrongly made structural changes in the PROD model directly, rendering the model out of sync.
* Confirm back to the history, and make a copy.
* Roll model forward to the latest user change history ID with “unlink revision created after this restore point” flagged. This deletes the auto saved revision tag from copying the model. There are now no unsaved structural changes between the DEV and PROD model. The sync is retained now.
* Add a new revision tag in Dev model and confirm the sync.
Use case 3: Clearing the model / revision tags
Though you can delete the revision tags now, I personally believe you should not do it too much. I still believe building the model incrementally is less logically confusing, especially for a big group of developers and stakeholders.
‘How I Built It’ video
https://play.vidyard.com/fmwjErKhZmkjVQHPGjai29
Questions? Leave a comment!
…………….
References:
* My colleague Petr Pavlenko (@peter.pavlenko) for helping out when one of my customers was wanting to send the PROD model back to history. Kudos to Petr!
* Article: How to roll back a production model to recover lost data
* Article: Save incomplete changes when synchronizing in ALM
-
2026 certificate maintenance for Certified Master Anaplanners
The 2026 Certified Master Anaplanner Program has begun, and there is incredible opportunity for 2026 Certified Master Anaplanners (CMAs) to demonstrate their thought leadership, technical expertise, Anaplan championship, and mentorship capabilities across the entire Anaplan ecosystem.
At their core, a Certified Master Anaplanner is someone who elevates others across the Anaplan ecosystem through the many ways they share their expertise. This includes mentoring others, sharing community perspective and technical architecture thought leadership, demonstrating innovative solutions, providing product feature insight, ideating and inspiring others in the Anaplan Community to help define the future of the platform, leading CoE development, building innovative roadmaps to scale the platform for business decision-making, and championing Anaplan in the competitive market.
Engagement zones
The 2026 CMA contribution activities list is attached to this post and available for CMAs to download:
Download the list of 2026 Contribution Activities
2026 CMA Contribution Activities.pdf
Each contribution activity is mapped to four engagement zones to help articulate how Certified Master Anaplanners are driving impact within the Anaplan ecosystem. As mentors, thought leaders, Anaplan Champions, and technical experts, Certified Master Anaplanners play a critical role in elevating the broader ecosystem and driving value through the ways they share their expertise.
Each engagement zone is important to the Certified Master Anaplanner community, the entire Anaplan ecosystem, and the Anaplan Community. Highlighting these zones is intended to help you easily align your experience and interests with activities that best suit where you want to make impact. CMAs are encouraged to focus on a primary engagement zone or pursue a blend of activities across zones — with the opportunity for some to complete activities in all four engagement zones during 2026.
Contribution activities will continue to be reviewed and updated throughout 2026 to reflect evolving priorities and areas of impact across the Anaplan ecosystem.
Contribution activities will continue to evolve throughout 2026, with new opportunities introduced regularly to reflect where Certified Master Anaplanners can have the greatest impact. This list will be refreshed at least quarterly, giving CMAs ongoing ways to engage, contribute, and be recognized for the value they deliver across the Anaplan ecosystem.
CMAs are encouraged to check back regularly and plan contributions early to take advantage of new opportunities as they are introduced.
Certification maintenance requirements
Certified Master Anaplanners are expected to actively contribute throughout 2026 and must meet two requirements to renew certification for 2026. These requirements remain consistent with prior years.
Contribution activity requirement
* Complete contribution activities totaling 400 points by December 15, 2026.
* The full contribution activity requirement is due in December; however, CMAs are strongly encouraged to show progress or have a communicated plan in place by the mid-year check-in.
* To support proactive planning and visibility, a mid-year check-in will be conducted between June and July 2026, with 200 points completed or confirmed by July 31, 2026 through planned, communicated activities
* CMAs are encouraged to report contribution activities as they are completed rather than waiting until deadlines
Technical (recertification exam) requirement
* Pass the proctored Certified Master Anaplanner recertification exam by December 31, 2026 (the exam must be passed, not just scheduled)
* The study guide and recertification exam will be available beginning July 8, 2026
* Recertification exam details are available in the 2026 Recertification Information resource
* CMAs should review the Recertification Exam Registration Instructions course in the Anaplan Academy CMA Program Maintenance learning path, which includes step-by-step guidance and the required registration code
Important clarification on recertification exam timing
The Certified Master Anaplanner recertification exam is required every two years. For 2026, the following applies:
* Certified Master Anaplanners who did not take the proctored recertification exam in the prior year — including Japanese-language learners awaiting the release of the Japanese exam and individuals who were granted a one-year extension due to extenuating circumstances — will need to complete and pass the proctored recertification exam in 2026.
* Certified Master Anaplanners who took and passed the proctored recertification exam to renew certification for 2026 have fulfilled the technical requirement for the two-year cycle.
* Newly certified Master Anaplanners in 2025 or 2026 have two years from the date of their initial exam before their first recertification exam is required.
If you are unsure if you need to take action to fulfill the technical requirement in 2026, please contact MasterAnaplanners@anaplan.com for confirmation.
Program terms, conditions, and contact information
Certified Master Anaplanners are responsible for remaining informed of the program policies and requirements that govern certification maintenance and participation.
Please review the 2026 Certified Master Anaplanner Program Terms and Conditions.
Please download and review the 2026 Certified Master Anaplanner Program Terms and Conditions
2026 Certified Master Anaplanner Terms and Conditions.pdf
CMAs must also ensure their contact information remains accurate and up to date, including the email address associated with their Certified Master Anaplanner Program participation. Changes to employment or email address should be addressed promptly to avoid disruptions to program communications.
For guidance on updating your email address, including temporary updates during employment transitions, DO NOT CREATE A NEW ACCOUNT. Instead, email the Academy help desk (academy@anaplan.com) to request an update to your learner and Community email address.
If you are a Certified Master Anaplanner who has any questions about the requirements for annual certification maintenance, your status, or how to engage, please email MasterAnaplanners@anaplan.com
If you are interested in the Certified Master Anaplanner Program and wish to learn more about how to become a Certified Master Anaplanner, please review the resources here.
-
Enabling ALM for an existing live business model
Author: Abhishek Singh, Certified Master Anaplanner & Engineering Manager at ABINBEV.
Application Lifecycle Management (ALM) is one of the most valuable governance features available in Anaplan. It allows model builders to make, test and validate structural changes in a Development model before deploying them to Production, reducing the risk of impacting business users who rely on the model every day.
Many organizations still have legacy models that were built before ALM became a standard implementation practice. Over the years, these models often grow in size and complexity with multiple developers making changes directly in the live model. While this approach may work initially, it becomes increasingly difficult to manage as the model evolves and business dependency on it increases.
Some of the common challenges seen in such models include:
* No clear separation between development and production activities
* Limited visibility into structural changes made over time
* Increased risk of accidental impact to end users
* Reduced governance and auditability
* Difficulty supporting multiple developers working on enhancements simultaneously
For these reasons, enabling ALM is often one of the most important steps in establishing a sustainable development and release process.
The approach below can be used when introducing ALM into an existing Standard Mode model that has been actively used by business users for several years.
1. Create a backup before making any changes
Before starting any ALM preparation activities, create a backup copy of the live business model.
This provides a recovery point should anything unexpected happen during cleanup activities, Production List configuration or ALM enablement. Although the process is generally straightforward, having a backup available provides additional confidence throughout the transition.
2. Perform model cleanup
Before creating separate Development and Production environments, it is a good opportunity to address any technical debt that has accumulated over time.
Typical cleanup activities may include:
* Removing unused imports and import data sources
* Renaming imports and actions using a consistent naming convention
* Deleting redundant modules, lists, line items and saved views
* Removing unused actions and processes
* Reviewing model size and identifying optimization opportunities
* In the clean-up process, provide notes to objects for better audit trail in future
Carrying unnecessary artifacts into both Development and Production models only increases complexity later. Performing cleanup upfront helps establish a cleaner foundation for ALM.
3. Review and eliminate unnecessary SELECT statements
One area that deserves special attention before enabling ALM is the use of hardcoded references in formulas.
Review formulas that use SELECT statements and identify whether they reference list members that may eventually become Production Data.
Where possible:
* Replace hardcoded member references with mapping modules and LOOKUPs
* Remove SELECT references tied to lists that will become Production Lists
* Retain SELECT references only where they are supported and appropriate, such as:* Top Level items
* Versions
* Native Time functions and references
* YTD, YTG, Current Period and similar Time-based references
This step is particularly important because Production Lists cannot be structurally referenced through hardcoded member selections.
Note: One practical lesson learned from many implementations is that replacing a SELECT with a LOOKUP should not be treated as a simple formula change. In some cases, a direct replacement may not produce the same result. It is always worth validating outputs carefully and following a structured testing approach before making changes in bulk.
4. Identify and configure Production Lists
The next step is to review all lists and determine which ones should be managed directly by business users in Production.
Production Lists allow data maintenance without requiring structural model changes or ALM synchronizations.
When identifying Production Lists, carefully evaluate any downstream dependencies, integrations, formulas, actions and hierarchies that rely on those lists before converting them to Production Data.
A little extra analysis at this stage can help avoid rework later.
Note: If any list was unintentionally left as a standard list during the initial ALM setup, it can still be converted to a Production List later. The change can be made in the Development model and then synchronized to Production through ALM. Existing list data will be retained and once the synchronization is complete, new list members can be added and maintained directly in the Production model without requiring further structural changes.
5. Review import actions and processes
This is one of the most commonly overlooked areas when enabling ALM.
Review every import action and process to identify hardcoded mappings that may create issues after lists are converted to Production Data.
Pay particular attention to:
* Fixed list member mappings
* Hardcoded parent assignments
* Source-to-target mappings that assume specific list members will always exist
Once a list becomes Production Data, import actions should not rely on hardcoded members that may change over time.
Where required:
* Replace hardcoded mappings with mapping modules
* Use code-based matching
* Implement dynamic lookup logic
* Ensure imports remain scalable as new Production List members are introduced
The objective is to make integrations and imports as flexible as possible so they continue working without requiring structural updates.
6. Validate existing integrations
Before moving further, it is important to document the current integration landscape.
This should include:
* Inbound integrations
* Outbound integrations
* CloudWorks schedules
* API-based integrations
* Middleware jobs
* ETL processes
* Current Workspace IDs
* Current Model IDs
Having this information readily available is extremely useful during validation, troubleshooting and post-deployment support.
7. Create the initial revision tag
Once cleanup activities and Production List identification have been completed, create a Revision Tag on the existing Standard Mode model.
This Revision Tag becomes the baseline from which ALM will be established.
Think of it as the starting point for your Development and Production relationship.
8. Create the Development model
Using the baseline Revision Tag, create a new model from the revision.
This new model will become the Development environment where all future structural enhancements, fixes and testing activities will take place.
At this stage:
* Development Model = Standard Mode
* Live Business Model = Candidate Production Model
Future development activities should be directed toward the Development model rather than the live business model.
9. Temporarily pause integrations
Before converting the live model into Production Mode, it is advisable to temporarily pause scheduled integrations and automated processes.
As a precaution:
* Pause or retire scheduled integrations
* Pause CloudWorks schedules if applicable
* Ensure no structural changes are being made during the transition
Just as important as the technical activity is communication. Make sure the relevant support teams, integration owners and business stakeholders are informed beforehand so there are no surprises during the transition window.
10. Convert the live model to deployed mode
After all prerequisites have been completed, enable Deployed Mode on the existing live business model.
This model now becomes the Production environment.
In Deployed Mode:
* Structural changes are restricted
* Business users continue maintaining Production Data
* Enhancements are deployed through ALM synchronization from Development
At this point, the organization officially moves to an ALM-driven operating model.
11. Validate ALM synchronization
Before opening the environment for active development, perform a simple end-to-end synchronization test.
A typical approach would be:
* Make a small structural change in the Development model.
* Create a new Revision Tag.
* Synchronize the change to Production.
* Confirm the synchronization completes successfully.
A successful deployment provides confidence that both models are ALM compatible and correctly configured.
12. Perform end-to-end validation
After the first successful synchronization, perform a broader validation exercise.
Areas that should be reviewed include:
* UX pages and dashboards
* Imports and exports
* Integration processes
* Production Data maintenance
* Security roles
* Selective Access
* Workflow functionality, where applicable
* Model-to-model imports
Although technical validation is important, business validation is equally critical.
It is a good idea to involve model administrators, process owners or key business users and ask them to perform high-level testing. The objective is to confirm that nothing has changed from an end-user perspective and that day-to-day processes continue to work as expected.
Business sign-off should be obtained before considering the ALM setup complete.
13. Re-enable and validate integrations
Once validation activities are complete:
* Re-enable integration schedules
* Resume CloudWorks jobs
* Validate inbound and outbound data movement
* Monitor the first few execution cycles closely
In most situations, integrations continue to work without modification because the original live model remains the Production model. As a result, the Workspace ID and Model ID remain unchanged.
This is one of the biggest advantages of converting the existing live model into Production rather than replacing it with a copied model.
Important consideration when using a copy model as production
In some situations, organizations may choose to designate a copied model as the new Production environment.
While this approach is possible, it introduces additional effort because the copied model receives a different Model ID.
As a result:
* Integration scripts may require updates
* CloudWorks connections must be reconfigured
* Middleware configurations may need modification
* Model-to-model imports must be remapped
* Upstream and downstream integrations require validation
* API-based integrations need to be updated with the new model reference
For this reason, many organizations prefer converting the existing live business model into Production and creating a separate Development model from the baseline revision whenever possible.
Key success factors
Successfully enabling ALM is not just a technical exercise. It requires coordination between multiple teams, including:
* Business stakeholders
* Anaplan development teams
* Integration teams
* Platform administrators
The technical steps themselves are usually straightforward. The real success comes from planning the transition properly, validating impacts early and ensuring all stakeholders are aligned throughout the process.
Once implemented, ALM provides a strong foundation for controlled releases, improved governance, reduced production risk and a more scalable long-term operating model.
Closing thoughts
While the steps above provide a structured approach to enabling ALM on an existing live model, there is rarely a one-size-fits-all solution. Factors such as model complexity, workspace constraints, integration landscape and business operating procedures can all influence the implementation strategy.
If there are additional considerations, lessons learned or best practices that you've encountered during your own ALM implementations, please share them in the comments.
-
How I Built It: Route planning
How I Built It: Route planning — The “Traveling Salesman Problem”
This ‘How I Built It’ video presents an Anaplan model that simulates a simplified “Traveling Salesman Problem” by using a fixed set of five cities and generating all possible route combinations. Users input a list of cities, and the model systematically builds every possible sequence of travel to ensure that all routes are evaluated.
After generating these combinations, the model calculates the distance for each route using built-in Anaplan Polaris functions. Trigonometric functions such as TORADIANS(), SIN(), COS(), and ACOS() enable distance calculations based on latitude and longitude, allowing the model to dynamically compute distances between each pair of cities. The total distance for each route is then summed across all legs of the journey, producing a single value that represents the full travel path. Repeating this process across all routes creates a complete set of comparable route distances.
The key takeaway is that the model shows how Anaplan can handle complex optimization problems using native functionality, combining list-driven structures with formula-based calculations. The design is also relatively scalable, as additional cities can be included by extending lists and line items, although the number of combinations increases rapidly. More broadly, this approach highlights how Anaplan can support analytical use cases such as route optimization, scenario evaluation, and decision support without requiring external tools or exporting data to separate models to leverage Optimizer.
https://play.vidyard.com/VkMw35H93Hb4zGZaF8t3vk
Questions? Leave a comment!
……………
All 'How I Built It' tutorials can be viewed here.
-
How I Built It: Workflow-centric approach to designing Anaplan projects
Author: Damien Bouquier has been a Certified Master Anaplanner for 5+ years and has developed solutions across a wide range of industries for FP&A, supply chain, and sales operations planning use cases.
Shifting gears: From dashboard-centric to workflow-centric applications
Are your users getting lost in a sea of dashboards every time they log into Anaplan? It’s time to rethink how we build enterprise applications.
In this video, we explore the powerful shift from a dashboard-centric to a workflow-centric approach. Most applications are designed from a « global view point » in mind, but end-users don't experience the process that way: they just want to get their specific tasks done efficiently.
By focusing on the process as the entry point, we can:
* Reduce friction and confusion for users.
* Provide role-based, personalized task lists.
* Replace manual follow-ups (emails, spreadsheets) with embedded governance.
* Align the application with real-world business operations.
Stop building for data exploration and start building for execution. Watch the video to learn how to transform your user experience and drive better adoption across your organization!
The main takeaways:
* The process as an entry point: The user should not have to look for where to go; the application must guide him directly to the tasks that are incumbent on him.
* Role-by-role customization: Avoid generic dashboards. Each profile (analyst, manager, etc.) must have a clean and specific view of its responsibilities.
* Action rather than navigation: Menus should no longer be lists of pages, but lists of concrete actions (e.g. "Approve budget").
* Integrated governance: Progress monitoring and validations must be done within the tool, eliminating the need for reminders by e-mail or external Excel files.
* Abstraction of technical complexity: The user does not need to understand the technical architecture or modules of the tool to be effective; he only needs to interact with the business process.
How I Built It
https://play.vidyard.com/jbf6h91EStfnbp6YQF4T9G
Questions? Leave a comment!
.png){kind=icon}
