Author: Sanja Boll is a Certified Master Anaplanner and Sr. Solution Architect at GlobalFoundries.
Anaplan’s Data Orchestrator (ADO) is very effective tool to import, transform, and load data into your Anaplan models. When used correctly, it can cut your data integration and transformation efforts by 50%, however maximizing its benefits does require a bit of experience. Below are the lessons I have learned while leveraging ADO at GlobalFoundries:
Multiple transformation views are better than one
- You will often see better performance and improve the auditability of your data transformations when you create multiple transformation views with your dataset, rather than combing all steps into one view.
- Additionally, ADO will process data transformations in a default order within a transformation view, not the order you apply it in. The order is:
- Join
- Calculate columns
- Detail filters
- Aggregations
- Aggregation filters
- Union
- Remove duplicate rows
- This means that if you want to adjust your source data to remove duplicate rows and then create a UID based on logic, you need to create 2 transformation views. The first view will remove the duplicate views. The second view will create the UID.
Establish consistent naming conventions
- As shared in my above bullet, you may need to create multiple transformation views to accomplish your desired data output. To make it clear to the rest of your team what each transformation view is doing, make sure to set naming convention expectations early. While you can always use the “Map” feature to view the progression of your data from source to transformation to model link, it is more time consuming to analyze the data map than it is to scroll through your transformation views. Here’s an example of a helpful transformation view naming convention:
- Dataset Name_ Transformation View # _ What the transformation view is doing
- An example would be “Purchase Orders_TV2_Filter Current Period”. This tells your Center of Excellence (CoE) team that this is the second transformation view of your PO dataset and you are filtering to the desired data period. If I were a model builder who needed to tweak the transformations of this dataset, having the transformation views labeled this way makes it easy for me to identify exactly where I need to make the change.
Be careful when you delete a transformation view
- Like anything in Anaplan, you are allowed to hit the delete button if you no longer need an item in your build. Unlike an Anaplan model, however, you cannot revert ADO. This means that if you delete a transformation view and then realize you actually needed it, you can’t undo the deletion. You will need to rebuild it. Some other implications to keep in mind when deleting a transformation view are that you can break downstream transformations that rely on the view you deleted. If the downstream transformation views are broken, your model link will be broken too. You won’t be able to run the model link until you add a new source.
Leverage dataspaces for sensitive datasets
- ADO allows you to create separate dataspaces with access controls. This is a great way to leverage ADO for sensitive data, such as Workday data for your workforce planning use case, without allowing all of your integration admins the ability to view the data. Access to dataspaces is granted to integration admins by the tenant admin in the “Administration” section of Anaplan.
Keep an eye out for new connectors
- There are three ways to get data into ADO:
- External source systems with connectors
- Your Anaplan models
- Local files
- I find that the most benefit comes from connecting to external source systems as you get to shorten the turnaround time of your integrations. Currently, there are 13 external connectors available to systems such as Amazon S3, Google BigQuery, Salesforce, and SAP, however Anaplan is actively working on adding more options. Redshift, for example, is currently available with basic authentication. Eventually it’ll be available with SSO, which I personally am quite excited about.
ALM-ing in ADO requires cloning
- When you push your integration build to Production, ADO will not automatically update your model links to your Production model. To connect your link to the proper model, you will need to go to ADO > Links and find the desired link you wish to remap. Then, click the three dots to the right of the link and select “Clone to ALM Models”.
Hopefully these tips help you to save time and get a quicker ROI on your ADO investment. Happy planning!
