Calculated Codes using Attributes - Best Practices

ebayliss

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?

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 

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!

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.