This is part 1 of a multi-part series geared towards enriching the finance organization hierarchy configurations. The goals are to maximize the utilized value of the hierarchies and provide guidance in how to better use and manage hierarchies.
Basic Workday guidance and training focuses the hierarchy use for the FDM in support of three basic activities:
Reporting
Security
Business Processes
I am going to add to and extend deeper knowledge on those three basics with guidance on how to work with them proactively to derive more direct value, as well as enable downstream capabilities two or three steps away from the basic setup your Workday partners put in place when you were initially deployed.
Through this series, I’m going to add to your understanding of Workday Hierarchies and give you a few more methods and insights for how to use Organization Hierarchies in Workday. Here are a few examples:
Create and utilize multiple Hierarchy verticals for the same Organization
Create Lookup Hierarchy Calc Fields that precisely identify the various rollup models
How enhanced Hierarchy models Planning and Budgeting at the Hierarchy node level
Enables Virtual Plan/Budget Models
Enables budget checking at a Hierarchy node level
Better for Adaptive Planning
Give Outline Structures a steroid boost
Refine the “level” structures to enable controls and boost reporting opportunities
Enforce or restrict “Skip Level” within the Hierarchy Structures
In my nine years of experience, I've found that there is a lack of solid conceptual understanding when it comes to various Workday configurations and tasks. The hierarchy configurations in nearly all the clients I’ve worked with have been sub-optimal. There is a myriad of reasons why, but that’s best done during a happy hour session. We’re going to focus here on starting to add the knowledge and enhancements to get closer to optimal and create more value.
Part 1 – Terminology Upgrades
Workday uses the term Hierarchy to refer to both a top to bottom vertical layout, as well as the individual containers within that structure. That’s very ambiguous and does not allow for a proper discussion about design. So we are going to add to our hierarchy lexicon with the following. Additionally, it is important to write and speak in long-hand so I’ll use these terms very robustly to ensure clarity:
Hierarchy Vertical | Use when referring to the overall hierarchy construct. It’s important to understand that most Organization, except Supervisory Org, can have multiple Hierarchy Verticals. This enables the client to create multiple rollup structures to support specific objectives, whether it be reporting, business processes, security, etc….
Note: Each Hierarchy Vertical is identified by its Top Level |
Top Level Hierarchy Node | All vertical hierarchical relationships have one and only one “Top Level” hierarchy node. You often see this as a sub prompt category.
Note: The advanced configuration of a Hierarchy Structure and its levels can only be applied to a Top Level node. |
Hierarchy Level # | Levels refer to the horizontal layers created by hierarchy nodes through the Superior/Subordinate (parent/child) relationships. Levels are implied by default as the hierarchy nodes are laid out. But Levels can also be explicitly defined, named and enforced by creating a Hierarchy Structure on the Top Level Hierarchy Node.
Note: Organization Subtypes are used to define and/or name levels |
Superior or Subordinate | This simply refers to the relationship between two Hierarchy Nodes and can be changed using the Reorganization Related Task.
Note: Member values are identified as “Included In”, not as superior or subordinate. |
Hierarchy Node | Hierarchy Nodes are the core container objects within the hierarchy layout. They are client created and named, may contain Members or other Hierarchy Nodes, and have Superior, Subordinate or Included In relationships with other objects. Another key attribute is that each Hierarchy Node can be assigned a SubType value (defined later) OR may have other attributes associated to it depending on the Type of Organization or Worktag it is.
Note: Hierarchy Nodes CANNOT be reused across Hierarchy Verticals |
Members | Members are the actual Organization or Worktag values themselves. These are the objects assigned to the transactions. Members are “Included In” hierarchy nodes. |
More Standard Terms:
Hierarchy Node
It is important to understand that Hierarchy Nodes are not used in recording transactions. Their primary function is in Reporting and to streamline management of security, business processes or custom validations constructs. Serving as a primary object in reporting, hierarchy nodes have a great deal of flexibility. But in supporting the management of security and business processes, hierarchies must also be carefully planned and actively managed to avoid downstream conflicts. With that in mind, there are a few general attributes of Hierarchy Nodes which should be understood.
Attribute of Hierarchy Node | Description |
Organization Code | This is effectively a Short Name or some simple value that can be used to clearly define the Organization when a long name is not appropriate. It can be defined to facilitate quick search, enabled as a prefix or simply for presentation benefits.
*It is NOT an ID value to be used for integration. It can be the same value, but the code is not restricted to be unique, it is only a presentation item. |
Organization Type | The default Type name is normally in parallel to the underlying dimension such as Cost Center Hierarchy or Fund Hierarchy. More complex implementations will enable other names. Creating alternate types enables a client to more specifically target an objective, for Reporting, Security or other. |
Organization Subtype | The default Subtype normally created is the dimension name itself, such as Cost Center or Fund. The two more advanced use cases are to: 1 – To name and enforce Levels to enhance reporting, such as Groups and Departments 2 – To enable Cross-drilling within a vertical hierarchy. The Subtype can be leveraged completely independently of the Hierarchy layout itself. |
Rolls Up Organization Type | This identifies the specific Organization Type (dimension) which this hierarchy node rolls up. This references the underlying Transacting Organization (dimension), and therefore identifies the Members that can be “Included In” the hierarchy node |
It is strongly encouraged that initial deployments be very conservative in the hierarchy names and construct setup. Basic 1:1 scenarios are best until the client has locked down reporting and management basics. The client can then begin to build parallel constructs that might address very specific reporting or management needs…but only after the client is fully capable of managing a baseline setup.
Hierarchy Level (Organization Subtypes)
Hierarchy levels are the layers created when a hierarchy vertical is built. Hierarchy Levels are “implied” simply by the layout as the Superior and Subordinate relationships are established between hierarchy nodes. Think Parent/Child. However, Hierarchy Levels can also be “Explicitly” defined and enforced through the creation of a Hierarchy Structure and creating Organization Subtypes to explicitly name the levels.
As previously discussed, each Hierarchy Node requires an Organization Subtype. It is the combination of the Hierarchy Structure, which lays out the layered levels, and the assigned Subtype associates that Hierarchy Node to the Level.
Hierarchy Structures
Hierarchy Structures can only be created on Hierarchy Nodes identified as “Top Level”. That structure will be effective from top to bottom in that Hierarchy Vertical. A Hierarchy Structure is not required, but it’s strongly recommended that one be created and a basic framework laid out regardless. This is because, eventually, during implementation or after, the Hierarchy layout will be challenged, and it’s best to have at least a basic definition in place regardless if the Hierarchy Structure is enforced or not.
Workday Exception Most delivered Organization/Worktags and Custom Organizations use the “Maintain Organization Subtypes” to name and associate Organization Hierarchies to Levels within a named Hierarchy Structure. However, Ledger Account Summary, Revenue Category Hierarchy and Spend Category Hierarchy use the explicit “Maintain Hierarchy Levels” task to create “…Level Names…” which are then assigned within the named Hierarchy Structure. |
A Visual Reference of a Cost Center Hierarchy
The above diagram presents some of the components the terminology define. We will go through this in detail in my next post... Blog 102 The Finance Org Hierarchy Series – Walk through the All Cost Centers Hierarchy (keep an eye out for this future blog). As mentioned, it is important that we talk more clearly about hierarchies. The terminology I am emphasizing will be used directly to identify those elements that need to be configured to build more robust and value-add Hierarchies.
Author: Mark from Maryland
