This blog post offers an in-depth idea of the D365 organizational hierarchy and how you can deploy them to remove impediments to the smooth functioning of internal processes.
Organizational Hierarchy in Microsoft Dynamics 365 Finance
Businesses are structured entities. They cannot function without establishing coordination between the people working for them. On the other hand, smaller companies or start-ups prefer to have more flexible and horizontal structures. As start-ups do not have to manage large workforces and must quickly adapt to shifting trends in the market. Yet, large and mid-sized enterprises have established business processes that their employees must follow.
The above diagram represents the flat links in business operations without top-down hierarchies.
Why Do Large-Scale Enterprises Need Top-Down Hierarchies?
- Large-scale enterprises constitute several organized units. Though these units have different purposes, they must maintain healthy levels of coordination to meet the business goals.
- Likewise, hierarchies establish ordered links between these units to help them operate as a collective whole. In their absence, businesses cannot develop optimal levels of authority or delegate roles properly.
- Simply put, maintaining a seamless workflow becomes almost impossible if employees do not know to whom and for what they are answerable. The same principle applies to the units of a large company. In short, large businesses can implement several types of structures to manage their operations.
To summarize, businesses can implement several structures to manage their operations. These structures can be flat or top-down. Large enterprises tend to implement top-down hierarchies while smaller firms prefer flat systems.
Before we move to a detailed discussion about organizational hierarchy feature, it is important to make a distinction between two major types of D365FO hierarchies.
Positional Vs. Organizational Hierarchies
Following are the two distinct types of hierarchical structures in D365 for Finance and Operations:
Organizational hierarchies define the relationship between different sub-groups. These sub-groups make up an enterprise and are concerned with corporate processes.
On the other hand, positional hierarchies relate to the people working in an enterprise with discrete designations. Further in this blog, we will cover administrative structures and the organizational hierarchy feature. To learn more about positional hierarchies keep an eye on the Instructor Brandon blog.
The following illustration summarizes the differences between positional and organizational hierarchies.
The above diagram illustrates the fundamental differences between organizational and positional hierarchies in D365FO.
Real-World Vs. D365 Virtual Hierarchies
There are several limitations to defining and creating hierarchies in real life. Howeve, Microsoft D365 helps businesses move beyond these real-world limitations. Above all, it offers two additional benefits. Also, there is one important similarity between these two distinct types of hierarchies.
Benefits of D365 Hierarchies over their Real-world Counterparts
The two major advantages of D365 hierarchies are as follows:
Creating Exclusive Hierarchies for Internal Use
In the real world, a large number of external factors affect organizational structures. For instance, tax laws and financial reporting requirements can influence organizational hierarchy.
Hence, these external factors put limitations while defining hierarchies. This can create major hurdles while implementing adequate internal controls. However, these internal controls are vital for the wellness of your business.
On the other hand, D365 does not correspond to external legal requirements. Hence, gives businesses the resilience to create custom hierarchies to serve internal needs.
Creating Multiple Hierarchies for Parallel Reporting Structures
In the real world, each business entity can have only one hierarchy and legal structure. In contrast, D365 allows users to create multiple hierarchies for different business purposes. These multiple hierarchies help gain insights into the business from different perspectives. Users can define D365 hierarchies with unique purpose modules. These purposes include budgetary planning, managing purchase orders, and ensuring data security. Moreover, it would help to implement internal security policies, financial reporting, and overall business process management.
Besides, business leaders can create distinct views based on these hierarchies. They can obtain data reports and analysis corresponding to each view. So, an organization can define a separate view for external stakeholders and senior managers.
In addition, despite these differences, there are few similarities between real-world and D365 organizational hierarchies.
Similarity between D365 Hierarchies and Real-World Structures
The most important similarity between D365 organizational hierarchies and real-world structures is as follows:
Organizational Hierarchies and Data Security
Firstly, managers can deploy a D365 organizational hierarchy in real-world structures to manage data security. Also, hierarchies can set up different data access levels so that employees have conditional access to use materials.
Similarly, certain data sets are accessible to specific operating units. For this reason, employees of one unit cannot change, update or delete another operating unit’s information. This ensures the security of organizational data.
In short, unlike the real world, D365 allows users to create multiple hierarchies to serve different business purposes. These purposes can range from implementing internal security policies to maintaining external reports and managing purchase orders. Moreover, D365 hierarchies do not have to correspond to external legal requirements, This gives firms the flexibility to create custom hierarchies to serve internal needs.
Turn real-world hierarchies into
D365 architectural models
Defining Organizational Hierarchies in Microsoft Dynamics 365
Microsoft Dynamics 365 offers various in-built options and modules. These built-in options help to create customized and configurable hierarchies that best suit operational requirements. The two main building blocks of D365 hierarchies are legal entities and operating units. Therefore, businesses can define hierarchies by creating ordered relationships between these two building blocks.
As a result, deciding how to map out your firm’s type is essential to create a functional hierarchy. However, before initiating a discussion on D365 hierarchies, you must understand the differences between these two types of entities:
Understanding Differences Between Legal Entities and Operating Units
- Legal entities have a defined status under the law. Moreover, these entities are registered with the authorities and must follow the legal statutes
- The main business is always defined as a legal entity
- Above all, legal entities can open their bank accounts and own fixed assets like real estate
- Although, they have master data and financial dimensions that are not sharable with other legal entities. However, some financial parameters are shared across legal units
- Lastly, legal entities are stand-alone structures and do not have sub-types
- Operating units are subsidiaries of larger legal entities and do not have independent standing in the eyes of the law
- Also, sub-firms working under the main umbrella are defined as operating units
- These units are distinguished by their operational purposes and typically enjoy a certain degree of financial autonomy
- Moreover, operating units under the same legal entity share metadata, modules, ledger information, and parameters. Though, if required, operating units can override specific modules and parameters
- Lastly, operating units are divided into five types: cost centers business units, value streams, departments, and retail channels.
Below table draws a comparison between how different D365 functionalities behave for different units:
How Different Functionalities Interact with Legal Entities & Operating Units
|Sr.||Functionality||Legal Entity||Operating Unit|
|1.||Master Data||Must be set up for each legal entity.
Some master data is shared
|Shared among operating units|
|2.||Module Parameters||Must be set up for each legal entity||Shared among operating units|
|3.||Ledgers||Must be set up for each legal entity||Operating units borrow ledger information from legal entities|
|4.||Fiscal Calendars||Each legal entity has its own calendar||Shared among operating units|
|6.||Centralized Payments||Must be set up||Not required|
Breaking Down Operating Units
As mentioned above, we can further divide operating units into five types. Each of these types serves a different function and represents different units of a company. Consequently, without understanding the function that each of these types serves, it is impossible to plan Dynamics 365 hierarchies.
So, here is the breakdown:
Cost centers are units that do not directly contribute to revenue generation but are important for the smooth working of the enterprise. Examples of cost centers include quality control activities and logistics.
Business units represent the departments or divisions of a company. Typically, business units enjoy a certain level of financial and operational autonomy. Business units ensure data security and regulate data access to important financial information.
Unlike cost centers and business units, value streams do not represent entities within a company. Instead, they are a collection of certain business activities to complete a specific task. For instance, the process of manufacturing a product includes the procurement of raw materials, assembly, and packaging- all of these processes combined represent a value stream.
As the name suggests, organizations employ these operating units to map the departments and divisions of an enterprise in Dynamics 365. Additionally, departments consist of multiple cost centers. Examples include sales departments and accounting divisions. Moreover, in D365 Finance and Operations, we can also use departments to represent profit centers; in other words, we can model the units involved in revenue generation as departments.
Retail centers, such as e-commerce platforms or physical retail outlets, represent actual sales points. They are coherent units and help managers oversee the performance of their point of sales infrastructure. Choosing the right operating unit types will help improve overall organizational efficiency.
Summarily, legal entities and operating units are the core building blocks of D365 hierarchies. All hierarchies are defined by creating ordered relationships between these two building blocks. While legal entities are independent structures in their own right, operating units are sub-organizations and are divided into five sub-types. These units are used to model real-world organizational hierarchies in D365. Deciding how to map out your organizations in the form of legal entities and operating unit types, it is essential to create an accurate and functional organizational hierarchy.
This flow chart is a basic template for organizational hierarchy in D365 and the units that make up an organizational hierarchy.
A Step-by-Step Functional Guide to Create an Organization Hierarchy in D365
Step 1: Go to Modules > Organization administration > Organizations > Organization hierarchies.
Step 2: After that, in the Action pane, click New.
Step 3: Type a name in the Name field, and type a value. Click on Save.
Step 4: In the Purpose section, click Assign Purpose.
Step 5: In the list, find and select the desired record. Select a purpose to assign to your organization hierarchy.
Step 6: In the Assigned hierarchy section, click Add.
Step 7: In the list, mark the selected row. Find the hierarchy you just created. Click OK.
Step 8: In the Assigned hierarchy section, click View hierarchy.
Step 9: To add an organization, click Edit.
Step 10: Then click Insert to add the organization. In the list shown, select the type as a department. From the departments’ list, select those which you want to add. Then click Ok.
Step 11: Once you have made the changes, you can Save a draft.
Step 12: After that, click on Publish the changes.
Step 13: Select an Effective date in the date field and click on Publish.
Planning Your Organizational Hierarchy Good Business Practices
Following is a list of some good business practices that users must keep in mind while planning their organizational hierarchy in D365:
Hold a Manager’s Seat for 5 Minutes
Firstly, remember that creating an organizational hierarchy or structure is not a technical exercise. Therefore, before you open dynamics for finance and operations, make sure you envisage and conceptualize a complete model that best represents your enterprise’s workings.
For this reason, ensure that you gather in-depth feedback from heads of different departments, senior-level managers, and other people involved in your enterprise’s day-to-day workings.
Don’t Entangle Multiple Purposes with a Single Hierarchy
Do not try to achieve too much with a single hierarchy. As mentioned above, D365 allows you to create separate hierarchies for distinct purposes; use this feature. Additionally, if your company has a complicated or intertwined network structure, deploy multiple hierarchies to simplify the reporting and approval processes.
Avoid Unnecessary Updates
Since changes to an organizational hierarchy in D365 impact the workings of the entire enterprise, so make sure that you do not update your hierarchy too frequently. Also, test and cross-check a hierarchy before implementing it in D365.
Limit Update Access
In addition, make sure that only a few selected people have the authority to create, modify or delete hierarchies to minimize risk. More people playing around with the structure means greater chances of an error. Last but not the least, changes to organizational hierarchy in D365 are dated. You can make a draft hierarchy and schedule an effective date for the next week. The hierarchy will automatically update on the chosen date.
Also, you can update your hierarchy only once per day; this means that if you make a mistake and implement it, you won’t be able to revise it until the next working day. So, be very careful.
Before you start making an organizational hierarchy in D365, make sure you have thoroughly consulted the people who manage the day-to-day working of the enterprise since D365 organizational hierarchy feature is modeled after real-world structures. Moreover, be careful while assigning purposes to hierarchies; do not create multiple hierarchies for the same purpose. Also, make sure that only a few selected people have the authority to create, modify or delete hierarchies to minimize risk.
Let us create purpose-built extensions for your D365 organizational hierarchy
D365 Organizational Hierarchy: Conclusion
Hierarchies are central to the smooth functioning of large-scale organizations and Microsoft Dynamics for Finance and Operations facilitates the seamless modeling of these real-world structures. Much like the real world, D365 hierarchies map the relationships between different sub-units that make up an organization. Moreover, D365 allows business leaders to define multiple hierarchies based on their unique business needs. Managers can create views based on hierarchies that can be utilized to generate important analysis and reports. Dynamics hierarchies consist of two basic building blocks; Legal entities and Operating Units. Lastly, to formulate a functional organizational structure, users must have a clear idea of the purposes each of these building blocks serves and be able to use these blocks to create precise architectures.
At Instructor Brandon | Dynatuners, we always seek innovative methods to improve competitiveness and suit your Microsoft Dynamics 365 requirements. Our offerings are founded on defined procedures, industry experience, and product understanding. If you’re interested in consulting with our technical solutions experts on designing, implementing, and updating D365 organizational structures, don’t hesitate to Contact Us.
Above all, we also understand that defining organizational architectures is an iterative process. Organizations might need to update their structures based on evolving business needs and might need to create new hierarchies as new requirements pop up. For this reason, we do not implement and forget instead we provide continued support.