The process of designing a model will help you:

  • Understand the customer’s problem more completely.
  • Provide the big-picture view for building. (If you were working on an assembly line building fenders, wouldn’t it be helpful to see what the entire car looked like?)

Table of Contents:


Understand the Requirements and the Customer’s Technical Ecosystem when Designing a Model

When you begin a project, gather information and requirements using a number of tools. These include:

  • Statement of Work (SOW): Definition of the project scope and project objectives/high-level requirements.
  • Project Manifesto: Goal of the project – big-picture view of what needs to be accomplished.
  • IT ecosystem: Which systems will provide data to the model and which systems will receive data from the model? What is the Anaplan piece of the ecosystem?
  • Current business process: If the current process isn’t working, it needs to be fixed before design can start.
  • Business logic: What key pieces of business logic will be included in the model?
  • Is a distributed model needed?
    • High user concurrency.
    • Security where the need is a separate model.
    • Regional differences that are better handled by a separate model.
  • Is the organization using ALM, requiring split or similar models to effectively manage development, testing, deployment, and maintenance of applications? (This functionality requires a premium subscription or above.)
  • User stories: These have been written by the client—more specifically, by the subject matter experts (SMEs) who will be using the model.

Why do this step?


Results of this step:

  • Understand the goal of the project.
  • Know the organizational structure and reporting relationships (hierarchies).
  • Know where data is coming from and have an idea of how much data clean-up might be needed.
    • What lists currently exist and where are they are housed.
  • Know which systems the model will either import from or export to.
  • Know what security measures are expected.
  • Know what time and version settings are needed.

Document the User Experience

Front-to-back design has been identified as the preferred method for model design. This approach puts the focus on the end-user experience. We want that experience to align with the process so users can easily adapt to the model. During this step focus on:

  • User roles. Who are the users?
  • Identifying the business process that will be done in Anaplan.
  • Reviewing and documenting the process for each role.
  • The main steps. If available, utilize user stories to map the process. You can document this in any way that works for you. Here is a step-by-step process you can try:
  1. What are the start and end-points of the process?
  2. What is the result or output of the process? What does each role need to see/do in the process?
  3. What are the process inputs and where do they come from?
  4. What are the activities the user needs to engage in? Verb/object—approve request, enter sales amount, etc. Do not organize during this step. Use post-its to capture them.
  5. Take the activities from step 4 and put them in the correct sequence.
  6. Are there different roles for any of these activities? If no, continue with step 8. If yes, assign a role to each activity.
  7. Transcribe process using PowerPoint® or Lucid charts. If there are multiple roles, use swim lanes to identify the roles.
  8. Check with SMEs to ensure accuracy.
  • Once the user process has been mapped out, do a high-level design of the dashboards.
    • Include: Information needed.
      • What data does the user need to see?
      • What the user is expected to do or decisions that the user makes.
    • Share the dashboards with the SMEs. Does the process flow align?

Why do this step? 

This is probably the most important step in the model-design process. It may seem as though it is too early to think about the user experience, but ultimately the information or data that the user needs to make a good business decision is what drives the entire structure of the model.

On some projects, you may be working with a project manager or a business consultant to flesh out the business process for the user. You may have user stories, or it may be that you are working on design earlier in the process and the user stories haven’t been written. In any case, identify the user roles, the business process that will be completed in Anaplan, and create a high-level design of the dashboards. Verify those dashboards with the users to ensure that you have the correct starting point for the next step.

Results of this step:

  • List of user roles.
  • Process steps for each user role.
  • High-level dashboard design for each user role.

Use the Designed Dashboards to Determine What Output Modules are Necessary

Here are some questions to help you think through the definition of your output modules:

  • If the dashboard is for reporting purposes, what information is required?
  • If the module is to be used to add data, what data will be added and how will it be used?
  • Are there modules that will serve to move data to another system? What data and in what format is necessary?

Why do this step?

These modules are necessary for supporting the dashboards or exporting to another system. This is what should guide your design—all of the inputs and drivers added to the design are added with the purpose of providing these output modules with the information needed for the dashboards or export.

Results of this step:

  • List of outputs and desired format needed for each dashboard.

Determine What Modules are Needed to Transform Inputs to the Data Needed for Outputs

Typically, the data at the input stage requires some transformation. This is where business rules, logic, and/or formulas come into play:

  • Some modules will be used to translate data from the data hub. Data is imported into the data hub without properties, and modules are used to import the properties. Reconciliation of items takes place before importing the data into the spoke model.
  • These are driver modules that include business logic, rules. 

Why do this step? 

  • Your model must translate data from the input to what is needed for the output. 

Results of this step:

  • Business rules/calculations needed.

Create a Model Schema

You can whiteboard your schema, but at some point in your design process, your schema must be captured in an electronic format. It is one of the required pieces of documentation for the project and is also used during the Model Design Check-in, where a peer checks over your model and provides feedback. 

  • Identify the inputs, outputs, and drivers for each functional area.
  • Identify the lists used in each functional area.
  • Show the data flow between the functional areas.
  • Identify time and versions where appropriate.

Why do this step?  

It is required as part of The Anaplan Way process. You will build your model design skills by participating in a Model Design Check-in, which allows you to talk through the tougher parts of design with a peer.

More importantly, designing your model using a schema means that you must think through all of the information you have about the current situation, how it all ties together, and how you will get to that experience that meets the exact needs of the end-user without fuss or bother. 

Result of this step:

  • A model schema that provides the big-picture view of the solution. It should include imports from other systems or flat files, the modules or functional areas that are needed to take the data from current state to what is needed to support the dashboards that were identified in Step 2. Time and versions should be noted where required. Include the lists that will be used in the functional areas/modules. 

For more information, check out 351 Schemas. This 10-to-15-minute course provides basic information about creating a model schema.

Verify That the Schema Aligns with Basic Design Principles


  • It is simple.
    • “Design should be easy in the sense that every step should be obviously and clearly identifiable. Simplify elements to make change simple so you can manage the technical risk.” — Kent Beck
  • The model aligns with the manifesto.
  • The business process is defined and works well within the model.


Hi @Alessio_Pagliano,





