Calculated Codes using Attributes - Best Practices

We are working on a project to migrate from an Employee Hierarchy to a Position Hierarchy in Anaplan and are looking from some input from the community on Code Creation best practices. Since we do not have a good external source of data for position code, we've decided to create our own Position code within Anaplan.

At first we thought of creating a calculated code based on the position attributes; e.g L3-NA-SW-01 for a level 3 manager in the SouthWest (SW) Region of North America (NA).

However, in our POC model, after creating the hierarchy codes this way, we realized that changes to the hierarchy structure would either require the codes to be refreshed based on the new attributes (e.g L3-NA-SW-01 becomes L3-NA-NE-01 after a re-org to the NorthEast region), or else the codes would no longer align to the latest position attributes.

Is it worth the effort to use attribute based codes if every time the attributes change we have to run actions to update the codes in all the downstream lists? Or is it just simpler to go with a system generated code that doesn't require updates after its creation?

Accepted answers

rob_marshall

@ebayliss

So, to answer your question, is the juice worth the squeeze? The answer would be no. Keep the codes as agnostic as possible and keep the attributes in a SYS module like you have it. Now, if a position requires more uniqueness, then you should add that to the code.

Rob

All comments

rob_marshall

@ebayliss

I guess it depends on the whether there are differences of the same position (L3) in North America vs. South America? Northeast vs. Southwest? Ideally, you would like the positions to be as agnostic as possible. If L3 does vary from NA to SA, then that should be in your code. Same for Northeast vs. Southwest, if there is a difference (not in hierarchy, but in what that position entails), then it should be part of the code.

Hope this helps,

Rob

ebayliss

Thanks Rob,

I would say there are differences between the two positions. We are using a System Module to contain all these attributes about a position. So from my example, the System Module would contain the level the position is on (L3), the Region (NA), and the Sub-Region (SW).

Is the benefit of having these attributes contained in the code worth the effort of having to update the code when these attributes change?

Couldn't we just use a System module to lookup those attributes when needed, and then we wouldn't need to run so many additional actions to update downstream lists with new codes every time attributes change?

Looking to see if the community has any experience working with calculated codes that require updating on a semi-frequent basis. Thanks again!

rob_marshall

@ebayliss

Rob

ebayliss

Great, thanks @rob_marshall! I agree keeping the code as agnostic as possible will reduce complexity and help with sustainability. Appreciate your input on this question.

Quick Links

Can you help?

Unanswered questions

Unable to use one page for multiple DEV models that are partially in sync
Hello, Our model builders are normally making changes to all structural changes in a DEV model. Because we are now in a Prod freeze and we don't want to move structural changes to PROD until end of year, we created a copy of the DEV model (standard mode) - 'DEV2' model, where we are only making changes to urgent issues…
Anaplan for Microsoft 365
Using the excel addin for Microsoft 365 when I try to add a card to import data I get the message 'Cannot insert data from a custom view'. I am not using a custom view. Any ideas what I am missing here?
Data Split between Many to Many Relationship Mappings
Hello Anaplan Community, I am encountering an issue with one of my development work and would be greatly appreciated your assistance. There are 2 different modules involved in my model: 1) INP01 Percentage Input by Product (Applies To: P3 List) 2) REP01 Percentage Split by Department (Applies To: Departments List) The…