Creating Hierarchical in Datahub

Hi All,

Recently i've started Level 2 Model Building and one of the topics in Datahub says -> it's best to create Hierarchical lists in Spoke model by taking data from views created by Flat lists in Data hub but what i feel is it's better to create Hierarchical list directly instead of creating Flat lists and then importing it into Hierarchical list in Spoke Models

I feel this will cover Necessary part in PLANS.

Please let me know whether this thought process is correct or something else needs to considered?

Thanks & Regards,

Sai Bharadwaj

linkedin.com/in/sai-bharadwaj

Accepted answers

All comments

Nagaraju

Hi @Sai_Bharadwaj_Venati ,

The idea of data hub is to hold data, serve as the single source of truth. Having said that, it is ideal to design the spoke models in such a way that entire planning activities can be done there itself.

If you create hierarchies inside the data hub, the problem is you have to go back to Data hub to "update hierarchy" if a new transactional data comes in. And then run the process again in Spoke model to get it updated. Why do the same operation twice? Segregation of duties is a "Logical" part of PLANS, which is getting violated here.

Hope this helps!

-Nagaraju

nathan_rudman

very often the DH is used to control the validity of data.

How can you control the validity of data without hierarchies ? No user I know can.

Also the DH should be the place where subsets are created/maintained. Very often on a COA or list of cost center,you'll need a hierarchy to be able to properly define a subset (is this account revenue, is this cost center profit center etc)

Misbah

@Sai_Bharadwaj_Venati

I would say a big NO. Apart from what other champs said you are more likely to see ignore messages as and when you load hierarchical lists of Spoke models from hierarchical lists of DH. There is no way you control what can be pulled.

"Import from List to List is a big NO"

Hope that helps

Misbah

rob_marshall

@Sai_Bharadwaj_Venati ,

If you haven't already, please take a look at this article: Data Hubs and Peak Performance where I discuss some best practices. Back to your question on hierarchies in the data hub, as usual, it can be viewed in different ways and while @nathan_rudman was on one side of the coin, @Misbah was on the other. Actually, both are correct, in certain instances.

What is a hierarchy really used for? Really, they are for aggregating data up and reporting and 99% of the time, this should not be done in the data hub. The only time this should be broken (creating hierarchies in the data hub) is when you are consolidating data sources and creating one source module/view for the data. All other times, you really shouldn't have them as they just take up space and, except for administrators, no one see's/uses them.

With that said, I do create them using views and actions at the beginning of projects, but that is only to make sure my views/actions are setup correctly. Once they have been validated, I delete the lists and actions, but still keep the views for the spoke model(s) to use.

Hope this helps,

Rob

Sai_Bharadwaj_Venati

@Misbah

Just want to clarify my understanding on what you're saying -> If i have hierarchical list in datahub and if i'm importing it into Spoke model list it will completely import all the data even if i don't want them and show it as ignored items.

By following this way basically i will lose some time for importing which is directly related to Performance

Kindly let me know if my understanding is proper and what do you mean by this statement - "There is no way you control what can be pulled" is this related to same (Pulling everything and ignoring of data) or something else?

Thanks for the Reply.

Regards,

Sai Bharadwaj

linkedin.com/in/sai-bharadwaj

Sai_Bharadwaj_Venati

@Nagaraju

Just a clarification -> In Level 2 MB this is the flow on how a product gets updated

1. Update a product in a flat list with code

2. Go to system module and update all the details

3. Import the data into Spoke model Hierarchy list

What i'm trying to say is : -

1. Update Product in Anaplan hierarchy list with all details mapped there itself

2. Import Hierarchical list into Spoke model directly.

Though i'm understanding there might be some issues but in both places i have to update in Datahub first then take the data into Spoke model. Where is the duplicacy in the above mentioned operation? R u referring i have to manually search and add the product into hierarchy? whereas with Anaplan suggested way i don't have to do the searching i can directly add them (I think it will save time if there a some many items in a list)

Thanks for the Reply.

Regards,

Sai Bharadwaj

linkedin.com/in/sai-bharadwaj

Misbah

@Sai_Bharadwaj_Venati

What I meant was that you can't apply filters on Lists to **** out Parents. Its like "Take all and Go" . That's why its recommended to create hierarchical views in Modules and then pull it.

JaredDolich

@Sai_Bharadwaj_Venati

You've got it. You're thinking is correct. L2 is a game changer IMHO.

You build the list flat in the DH.

You build a system module in the DH with all the details about the list including the code, name, and parent.

You build an import from the system module in the DH (source) to the spoke list (target)

Build the parents first and work your way down.

As @Misbah mentioned never import list to list - he covered all the reasons why.

As @rob_marshall mentioned read the data hub peak performance best practice. It's the best article you'll ever read, trust me.

One Exception:

Sometimes you need to test the data in the DH so you might need to build a structured list there. But once you're done with your test, remove the structured list.

Quick Links

Can you help?

Unanswered questions

Predefaulting A Feild in ANAPLAN
Hello Anaplan Community, I have a special requirement from a customer and would appreciate your input. Let me explain the situation: We have a hierarchy with three levels: Level 1, Level 2, and Level 3. Screen 1: Creation of Level 1 Items On this screen, the user selects a team. Based on their selection, an action runs to…
Looking for Anaplan End-Users to take a short survey!
We are looking for Anaplan end-users to provide feedback on their experiences with the Excel add-in. Interested individuals will respond to this 5-minute survey to help us understand personal needs and behavior when using the add-in. The feedback provided by survey takers is essential to the roadmap of Anaplan's products.…
CERTIFICATION BADGES - ANNOUNCEMENT
Anaplan Champions! The Community team just posted this announcement that certification badges may not be showing up on your profile probably until next year. Rest assured, you will get credit once you complete and pass the exams. https://community.anaplan.com/t5/Blog/Badges-Back-Soon/ba-p/123385