OEG Best Practice: Import action management best practices
An import action section can quickly become disorganized, making ongoing management challenging. Learn why this happens and explore steps to take to prevent this from occurring.
Import action section: why does it become disorganized?
Anaplan saves every import action that you perform, no matter what. For a new build, the entire model structure and design can change completely by the end of the project. For many deployments, you don’t know which imports you want to save, until you are much further along in the build.
Cleanup rules are hard to enforce if you have multiple users. With multiple builders, you are discouraged from deleting imports from other people, as you don’t want to interrupt their work.
Import action cleanup is generally saved for the very end of the deployment. Team members run into a time crunch, and when weighing other priorities, simply don’t invest the time to clean up this section. If you take no steps to codify your import actions during the build, delineating your “Final” imports from “Test” imports at the end can be an extremely difficult process.
Without proper guidance, deleting imports is a very intimidating process. Everyone knows that if you delete the wrong imports it can completely break your model; therefore, it’s always easier to just leave the import section unmaintained.
Below is an example that shows the difference between a well-maintained import section list and one that is not:
Additionally, below is an example of a model where not all sources are tied to actions. Tying all of your import sources to actions is another step to take to ensure that your model automation settings are as clean and transparent as possible.
Effect on process auditing and model longevity
The effect of an improved naming convention for imports is most evident in the model handoff process and, consequently, overall model longevity. It is not uncommon for Anaplan processes to be handed off to people who were not involved in the initial build. If you simply leverage the default naming convention for import actions, the ramp-up process is much more difficult. Using a customized naming convention makes it significantly easier for a new user to decipher what the model is doing and to audit the process if there is a problem.
Categories to create
-
LIST APPEND—intended to add additional items to a list.
-
LIST HIERARCHY—intended to update the parent value for list items.
-
LIST APPEND & HIERARCHY—intended to add additional items to a list and update the parent value for list items.
-
LIST SUBSET—intended to update whether or not list items are included in a subset.
-
Additional thoughts on List Imports:
-
All list imports are structurally the same and can perform updates to every listed category all at once (append, hierarchy update, subset update).
-
You should purposely separate these as different import actions to make your model easier to understand and more transparent to other users.
-
-
LIST ATTRIBUTES—as it is now best practice NOT to use List Properties, we now create LIST ATTRIBUTE modules that represent the same function.
-
These are simple modules, dimensioned only by the list in question with line items in place of list properties.
-
Put it right after the list import section to hopefully make it less confusing.
-
-
MOD DATA—general category for any import with the primary intent of feeding data into a module.
-
The example shown is from a simple deployment, where only one category was necessary; how complex you need to make this section will vary significantly based on the nature of your deployment.
-
Consider creating your naming convention based on either dimensionality, versions, or time (ie MOD DATA DISTRICT SEGMENT, MOD DATA CURRENT, MOD DATA HISTORICAL, etc.).
-
-
INPUT RESET—any import intended to reset an input value to either zero, blank, or other default value.
Separators and category labels
The separators and category labels are simply empty lists being imported into other empty lists; this minimizes the text footprint of these artifacts. To create a new separator or category label, simply select an existing divider, select import, and choose a separate existing divider as the import source.
If any of these import actions run by accident, nothing destructive will happen to your model. The names of the dividers look the same, but the number of spaces between the periods is different for each separator. Note that the divider and section label names need to different than any names you are using for any list or module names. Remember to add an “Imports Pending Review for Deletion” section at the very end—all new imports will show up under this header initially.
Enforce business rules to promote better import management
- Use a defined naming convention for all imports that you intend to repeat
- If you don’t have one, just start with the base example shown previously
- All repeatable actions must be mapped to a process
- Actions cannot be deleted without being removed from associated processes; this encourages you to perform your due diligence before removing an action.
- All actions not mapped to a process are pending deletion
- In the middle of a build, if you are crunched for time or a formal import naming convention has not been set, use an asterisk (*) to tag imports that you intend to save.
- All actions intended to be saved must have a descriptor in the notes section
- During a deployment, add import action cleanup as an agenda item on a weekly review
- For a live model, the import action review period will vary depending on the amount of change that occurs, but consider a quarterly review at a minimum.
Author Matthew Kuo.
Comments
-
Naming convention are very important ...why because, based on the names we can easily understand from where data is import/ export from the system .
1 -
Including an action sequencing id would be good specially when you have processes that has 5 or more actions involved. I've found a large percentage of defects I've had with processes/actions is that the actions have been executed in the wrong sequence. Simple example, you run an action that creates a level 5 list item before you ran the action that created the parent level 4 list item. So when you run the process you get an error that the parent list item you have mapped for level 5 item creation doesn't exist. So my actions would you usually have a sequencing id such as per example below
01 Brand Create List
02 Sub Brand Create List
03 Product Create List
04 SKU Create List
1
