The Institution area is used to define and maintain the business structure.
The business structure is the foundation for the entire implementation of the application; a substandard business structure could result in reconfiguration.
Important: It is very important to understand how the business structure relates to Authorities (security settings) before building the business structure.
There are five strict and interdependent organizational levels that make up the business structure.
Levels have a root, parent, child, and sibling relationship. A root level, does not have a parent level. A parent level is any level that has a sub-level known as a child. Sub-levels within a parent level are children. Children within a sub-level are siblings.
The the five default levels1 out-of-the-box without changing default application terminology are as follows and in this strict hierarchical order:2
*Positions are configured below the unit; a sub level within a level. Positions are jobs people are assigned to work.
To review preexisting terminology or rename a level to better fit your organization’s terminology go to Setup > General > Terminology. Renaming the levels or nodes changes the labels across this application - but does not change the inherit hierarchical level; for example, if you change the term Unit to Area, Area remains as the 5th level in the organizational structure.
The business structure has a strict hierarchy, each level must hang in the correct order, which means the position or positions hang from the Unit, that Unit hangs from a Station, that Station hangs from a Region, that Region hangs from an Agency, and that Agency hangs from an Institution.
Customers using Dimensions, configure Types located in Jobs and Business Structure; default field data flows one way (unidirectional) from Dimensions not bidirectional. Cross reference tables are used to match organization levels in this application to Dimension Types. Types are logical organizational levels, such as institution, agency, region, division, station, or unit. Types are used to identify Locations (levels) in this application. Locations are physical locations or logistical areas in your organization such as Battalion 1, Station 1, Station 2, Unit 1, Area 1, Cell 1, Line 1 and so on. This means a Dimensions node of Type WFTS_Station3 will be created as a Station, meaning station level or 4th level. A Location of X of Type WFTS_Station will create X at the Station level.
Most implementations use terminology to distinguish each of the five levels and down to the positions to create the business structure; however in some instances the five levels are not reflected in the business structure, when this occurs this application requires five levels to create the initial structure. For example, the most common case is Administrative personnel, which may encompass Human Resources, Payroll Department, Finance, Secretary... To configure areas that do not exist to fit the ‘five levels’ required consider a label that identifies that area of the business structure and facilitate mapping and or references to other areas within this application such as people filters, limits in setup, configuration lists, or mapping for integration purposes.
Example: Administration personnel. Abbreviate Administration (ADM):
(Institution Level)(Agency Level)(Region Level)(Station Level)(Unit Level)(Position)(Position)(Position)(Position)We recommend keeping naming conventions short, in the example above the labels are long for documentation purposes, text translation, and screen readability. If desired abbreviate the word Administration as in ADM. Also see related topic Administrative (Nonessential) Shifts.
Customers using Dimensions must create the five levels, although Dimensions does not enforce the number of nodes in a business structure when the business structure synchronizes with this application this application will create the missing organizational levels as undefined. Additionally, once the business structure hierarchy breaks with a node that is not using a location type associated with this application -the integration will not consider that node or any children of that node. For example, suppose the Unit node looks like this in Dimensions: Institution-> Agency -> Unit. When this configuration passes to this application it will look like Institution -> Agency -> <Undefined Region> -> <Undefined Station> -> Unit.