Skip to main content

Dynamic Hierarchy Policies in EmpowerID

Introduction​

EmpowerID’s Dynamic Hierarchies engine is like an autopilot for creating data-driven nested groups in systems like Active Directory and Azure Active Directory. The idea behind Dynamic Hierarchies is simple: organizations need collaboration or email groups for each location, company, division, department, and manager. Even more useful is the ability to generate nested groups based on the business hierarchy. For example, a group for each company can be nested inside a group for each department within that company. The information to power these rules can be found in HR systems, Active Directory, or other key systems. Dynamic Hierarchy policies are easily defined and leverage this data to create and maintain these valuable groups automatically.

The power of Dynamic Hierarchies lies in their ability to run completely automated without any costly human intervention. For example, when a new department is added to HR, it will automatically appear as a nested group. If Sarah gets promoted and has five new direct reports, her team gets its own distribution list. If your organization undergoes a complete reorganization, the new structure is created and maintained accurately. Dynamic Hierarchies save organizations time and money while improving users' ability to collaborate effectively.

Dynamic Hierarchy Policies in EmpowerID are an essential tool for automating the organization of personnel into groups or management roles. By leveraging attributes stored in the Person object, these policies enable organizations to dynamically create and maintain hierarchical structures based on real-time data. This automation not only reduces administrative overhead but also ensures consistency and accuracy in group and role management.

This feature is particularly useful for scenarios such as organizing employees by departments, regions, or roles, and it allows for seamless updates as data changes over time. EmpowerID's Dynamic Hierarchy is a flexible, scalable solution capable of supporting complex organizational needs.

Core Concepts of Dynamic Hierarchies​

Dynamic Hierarchy Policies rely on a few key components to function effectively. At the core of this feature are policies that define the rules and logic for group and role creation. These policies are executed through a series of automated jobs, each responsible for a specific step in the process. The process begins with the Dynamic Hierarchy Generation job, which scans the system's data to identify groups or roles that need to be created or removed. These actions are then queued in a shared Hierarchy Event Inbox for processing.

The Role of the Inboxes​

EmpowerID uses two shared inboxes to manage and process the transactions generated by Dynamic Hierarchy Policies. These inboxes ensure a modular and organized workflow, separating the identification of required changes from their execution.

  1. Hierarchy Event Inbox:

    • This inbox serves as the queue for hierarchy generation.
    • The Dynamic Hierarchy Generation Job identifies the groups or roles that need to be created or deleted and stores these transactions in the Hierarchy Event Inbox.
    • The Dynamic Hierarchy Provision Inbox Processor Job processes the records in this inbox, executing the necessary actions such as creating or deleting groups and roles.

  2. Membership Inbox:

    • This inbox serves as the queue for membership changes.
    • The Dynamic Hierarchy Membership Recalculation Job identifies membership updates needed for groups or roles and stores these transactions in the Membership Inbox.
    • The Dynamic Hierarchy Membership Inbox Processor Job processes the records in this inbox, ensuring that users are correctly added or removed from groups and roles.

Workflow Summary​

The process is modular, with specific jobs assigned to populate and process each inbox:

  • The Dynamic Hierarchy Generation Job populates the Hierarchy Event Inbox with transactions for creating or deleting groups and roles.
  • The Dynamic Hierarchy Provision Inbox Processor Job processes the Hierarchy Event Inbox and executes these transactions.
  • The Dynamic Hierarchy Membership Recalculation Job populates the Membership Inbox with transactions for membership changes.
  • The Dynamic Hierarchy Membership Inbox Processor Job processes the Membership Inbox to update memberships.

By using these shared inboxes, EmpowerID ensures efficient and scalable management of group and role lifecycle events, as well as membership updates. This approach allows for clear separation between transaction identification and execution, minimizing the risk of errors and improving maintainability.

Configuring Dynamic Hierarchies​

Policy Types​

Dynamic Hierarchy Policies in EmpowerID are designed to address a wide range of organizational needs, offering flexibility in creating groups, roles, and hierarchical structures. Each policy type serves a specific purpose, allowing administrators to tailor the Dynamic Hierarchy engine to their environment. Below are the key policy types and their functions.

Organizational Chart Groups​

Organizational Chart Groups allow EmpowerID to dynamically generate groups based on management hierarchies. These groups can be created using EmpowerID Person relationships or the ManagerPersonID attribute defined in a connected directory.

For each manager, EmpowerID creates a corresponding group in the designated organizational unit (OU). Direct report accounts are added as members of their respective manager's group. This approach provides a clear reflection of organizational structures within the group directory.

Person Attribute Management Roles​

Dynamic Hierarchy Policies can generate Management Roles and assign people to these roles based on specific attribute values, such as department names. When such a policy runs, EmpowerID evaluates the attribute values on Person objects and assigns individuals to the corresponding Management Roles. This allows for automated and consistent role management based on organizational data.

Two-Level Management Roles​

For more complex role-based hierarchies, EmpowerID supports the creation of Two-Level Management Roles. These policies evaluate two Person attributes, such as Title and City, to define both Management Role Definitions and the associated Management Roles.

Initially, a parent Management Role Definition is created based on the first attribute, while the specific Management Roles are generated from combinations of the first and second attributes. Once the roles and definitions are established, individuals are automatically assigned to the appropriate roles based on matching attributes.

One-Level Single Attribute Groups​

One-Level Single Attribute Groups are ideal for simple, attribute-driven group structures. This policy type creates groups based on the value of a single Person attribute, such as State. During execution, EmpowerID generates a group for each unique attribute value and assigns individuals with matching values to the corresponding groups.

For example, if the policy evaluates the State attribute, EmpowerID might generate groups such as "California Users" or "Texas Users," with members automatically assigned based on their State value.

One-Level Dual Attribute Groups​

One-Level Dual Attribute Groups expand on single-attribute policies by combining two Person attributes to define group membership. These policies are useful for creating non-nested groups for each unique combination of two attributes, such as State and City.

For instance, a policy might generate groups like "California-Los Angeles" or "Texas-Houston." EmpowerID evaluates each combination of the specified attributes and assigns individuals to the corresponding groups. These groups remain flat, without a hierarchical or nested structure.

One-Level Triple Attribute Groups​

One-Level Triple Attribute Groups extend the dual-attribute approach by considering three Person attributes to define group memberships. This allows for even greater granularity in group creation. For example, groups might be generated for combinations such as State, City, and Country.

EmpowerID creates a group for each unique combination of the three attributes, such as "USA-California-Los Angeles." Individuals are then assigned to the groups corresponding to their attribute values.

Two-Level Dual Attribute Nested Groups​

Two-Level Dual Attribute Nested Groups expands on dual-attribute policies by combining four Person attributes that are combined as two separate dual-attribute parings to define group membership. These policies are useful for creating nested groups for each dual-attribute pairing combination of two attributes, such as Country and State and then City and Office.

For instance, a policy might generate groups like "United States-California" and "Sacremento-Main Street" and then nest the city-office groups into the Country-state groups to create a fully meshed group combination of all four attributes.

Two-Level Attribute Nested Groups​

Two-Level Attribute Nested Groups introduce a hierarchical structure to group creation. This policy type uses two Person attributes to create a top-level group for the first attribute and nested groups for the second attribute.

For example, a policy evaluating State and City might create a "California" group with nested groups for "Los Angeles," "San Francisco," and "San Diego." Administrators can configure whether individuals are assigned to both the top-level and nested groups or only to the nested groups. Additionally, policies can be set to create top-level groups only when conditions for the nested groups exist, further optimizing the hierarchy.

Account Attribute External Roles and Locations​

Dynamic Hierarchy Policies can also generate external Business Roles and Locations based on Person attribute values. For example, attributes like Department can be used to create roles such as "Finance Role" or locations like "New York Office."

The Dynamic Hierarchy engine assigns individuals to these external roles and locations based on their matching attribute values, ensuring alignment with external systems and HR data.

Policy Configuration​

Configuring Dynamic Hierarchy Policies involves selecting attributes, naming conventions, and other settings specific to the policy type. Each policy type has unique configuration options to ensure that the generated groups, roles, or locations align with organizational needs. Below are the configuration details for each type of policy.

Organizational Chart Groups​

When configuring Organizational Chart Groups, administrators can specify attributes for external roles and locations, define naming conventions, and set actions for roles and locations that no longer meet criteria. The following settings are available:

  • External Role Level 1: The attribute used to generate the parent external role.
  • External Location Level 1: The attribute used to generate the parent external location.
  • External Role Level 2: If nesting roles, the attribute used to generate the first child external role.
  • External Location Level 2: If nesting locations, the attribute used to generate the first child external location.
  • External Role Level 3: If nesting roles, the attribute used to generate the second child external role.
  • External Location Level 3: If nesting locations, the attribute used to generate the second child external location.
  • Claim Matching Roles: Enables the Dynamic Hierarchy engine to adopt existing roles matching the criteria.
  • Claim Matching Locations: Enables the Dynamic Hierarchy engine to adopt existing locations matching the criteria.
  • Role Assignment Removal Delay (Minutes): Specifies how long to wait before removing users who no longer meet the criteria for roles and locations.
  • Empty Role Action: Determines the action for roles with no members:
    • No Action
    • Delete
  • Empty Location Action: Determines the action for locations with no members:
    • No Action
    • Delete
  • Naming Conventions:
    • Level 1 Naming Convention ('Value1'): Defines the name for parent roles and locations based on the Level 1 attribute.
    • Level 2 Naming Convention ('Value1''Value2'): Defines the name for child roles and locations based on the Level 2 attribute.
    • Level 3 Naming Convention ('Value1''Value2''Value3'): Defines the name for second-level child roles and locations based on the Level 3 attribute.

Person Attribute Management Roles​

Configuration for Person Attribute Management Roles focuses on assigning users to roles based on a specific attribute and defining actions for empty roles. Key settings include:

  • Attribute Name: The attribute used to determine the Management Role, such as Title or Department.
  • Naming Convention ('Value1'): Specifies the naming format for roles. For example, roles might be named "Engineering".
  • Empty Management Role Action: Specifies what happens to a role with no members.
  • Parent Management Role Definition: The base template for the role. By default, the "Blank Management Role Definition" is used.

Two-Level Management Roles​

Two-Level Management Roles allow administrators to generate hierarchical role structures based on two attributes. The following options are available:

  • Management Role Definition Attribute Name: The attribute used to define the parent role (e.g., Department).
  • Management Role Attribute Name: The attribute used to define the child role (e.g., Office).
  • Management Role Naming Convention ('Value1' 'Value2'): Specifies the naming format for roles. For example, roles might be named "Engineering - New York".
  • Management Role Definition Naming Convention ('Value1'): Specifies the naming format for parent roles.
  • Empty Management Role Action: Specifies the action for roles with no members.

One-Level Single Attribute Groups​

One-Level Single Attribute Groups create simple group structures based on a single attribute. Configuration options include:

  • Attribute to Group By: Selects the attribute used to define group membership (e.g., State).
  • Claim Matching Group: Allows the adoption of existing groups that match the criteria.
  • Mail-Enable Groups: Enables email functionality for groups.
  • Empty Group Action: Specifies what happens to groups with no members.
  • Delay Removal of Membership by X Days: Sets a delay period before removing members who no longer meet criteria.
  • Group Type: Defines the group type (e.g., Security, Distribution).
  • Dynamic Hierarchy Naming Convention ('Value1'): Defines the naming format for groups. For example, groups might be named 'State' Users".
  • Group Creation Location: Specifies the Organizational Unit (OU) for group creation.

One-Level Dual Attribute Groups​

One-Level Dual Attribute Groups use two attributes to define groups. Configuration includes:

  • First Attribute to Group By: The primary attribute used for group creation (e.g., State).
  • Second Attribute to Group By: The secondary attribute used for group creation (e.g., City).
  • Claim Matching Group: Allows the adoption of existing groups that match the criteria.
  • Mail-Enable Groups: Enables email functionality for groups.
  • Empty Group Action: Specifies what happens to groups with no members.
  • Delay Removal of Membership by X Days: Sets a delay period before removing members who no longer meet criteria.
  • Group Type: Defines the group type (e.g., Security, Distribution).
  • Dynamic Hierarchy Naming Convention ('Value1' 'Value2'): Defines the naming format for groups. For example, groups might be named "California - Los Angeles".
  • Group Creation Location: Specifies the Organizational Unit (OU) for group creation.

One-Level Triple Attribute Groups​

One-Level Triple Attribute Groups use three attributes to define groups. Configuration options include:

  • First Attribute to Group By: The first attribute used for group creation (e.g., Country).
  • Second Attribute to Group By: The second attribute used for group creation (e.g., State).
  • Third Attribute to Group By: The third attribute used for group creation (e.g., City).
  • Claim Matching Group: Allows the adoption of existing groups that match the criteria.
  • Mail-Enable Groups: Enables email functionality for groups.
  • Empty Group Action: Specifies what happens to groups with no members.
  • Delay Removal of Membership by X Days: Sets a delay period before removing members who no longer meet criteria.
  • Group Type: Defines the group type (e.g., Security, Distribution).
  • Dynamic Hierarchy Naming Convention ('Value1' 'Value2' 'Value3'): Defines the naming format for groups. For example, groups might be named "USA - California - Los Angeles".
  • Group Creation Location: Specifies the Organizational Unit (OU) for group creation.

Two-Level Attribute Nested Groups​

Two-Level Attribute Nested Groups create hierarchical group structures. Key configuration options include:

  • First Attribute to Group By: The primary attribute used for group creation (e.g., State).
  • Second Attribute to Group By: The secondary attribute used for group creation (e.g., City).
  • Add Users as Members at All Levels and Do Not Nest Groups: Determines whether users are added to all levels or only to the nested group.
  • Create Level 1 Groups Even if No Level 2: Creates top-level groups even if no nested groups exist.
  • Claim Matching Group: Allows the adoption of existing groups that match the criteria.
  • Create OU for Level 1: Creates a separate OU for top-level groups.
  • Claim Matching OU: Allows the adoption of existing OUs that match the criteria.
  • Mail-Enable Level 1 Groups: Enables email functionality for top-level groups.
  • Mail-Enable Level 2 Groups: Enables email functionality for nested groups.
  • Empty Group Action: Specifies what happens to groups with no members.
  • Delay Removal of Membership by X Days: Sets a delay period before removing members who no longer meet criteria.
  • Group Type: Defines the group type (e.g., Security, Distribution).
  • Level 1 Naming Convention ('Value1'): Defines the naming format for top-level groups.
  • Level 2 Naming Convention ('Value1' 'Value2'): Defines the naming format for nested groups.
  • Group Creation Location: Specifies the Organizational Unit (OU) for group creation.

Account Attribute External Roles and Locations​

Account Attribute External Roles and Locations enable the creation of roles and locations based on specified attributes. Configuration options include:

  • External Role and Location Attributes: Define attributes for parent and child roles and locations (up to three levels).
  • Claim Matching Roles and Locations: Enables the adoption of existing roles and locations.
  • Role Assignment Removal Delay (Minutes): Sets the delay before removing users who no longer meet criteria.
  • Empty Role and Location Action: Determines the action for roles and locations with no members:
    • No Action
    • Delete
  • Naming Conventions:
    • Level 1 ('Value1''): Naming format for parent roles and locations.
    • Level 2 ('Value1' 'Value2'): Naming format for first-level child roles and locations.
    • Level 3 ('Value1' 'Value2' 'Value3'): Naming format for second-level child roles and locations.

Configuring Calculation and Processing Schedules​

EmpowerID provides flexible options for scheduling the generation of hierarchies and recalculating group memberships. These settings allow administrators to control when and how often these processes run to ensure the system remains updated without unnecessary overhead.

Hierarchy Generation Schedule Settings​

Hierarchy generation is responsible for creating or updating groups, roles, and locations based on the defined policy. The following settings control how and when this job runs:

  • Hierarchy Generation Enabled: Enable this option to allow EmpowerID to generate hierarchies from the policy.
  • Hierarchy Generation Next Run: Specify the date and time for the next run of the Hierarchy Generation job.
  • Hierarchy Generation Schedule: Define the start and end dates for hierarchy generation.
  • Hierarchy Generation Interval: Set the frequency of the Hierarchy Generation job. Options include:
    • Once: The job runs a single time.
    • Minute Interval: The job runs "X" times every "Y" minutes, as specified. For example:
      • Iteration: 2, Interval: 24 minutes → Runs twice, with the second run 24 minutes after the first.
      • Run Indefinitely, Interval: 24 minutes → Runs every 24 minutes indefinitely.
    • Hour Interval: The job runs "X" times every "Y" hours, as specified. For example:
      • Iteration: 2, Interval: 24 hours → Runs twice, with the second run 24 hours after the first.
      • Run Indefinitely, Interval: 24 hours → Runs every 24 hours indefinitely.
    • Daily: The job runs once every "X" days at a designated time. For example:
      • Iteration: 2 → Runs twice, with the second run on the next day at the specified time.
      • Run Indefinitely → Runs daily at the designated time.
Membership Recalculation Schedule Settings​

Membership recalculation ensures group memberships remain aligned with the latest data. The following settings control how and when this job runs:

  • Membership Recalculation Enabled: Enable this option to allow EmpowerID to update group memberships on the defined schedule.
  • Membership Recalculate Next Run: Specify the date and time for the next run of the Membership Recalculation job.
  • Membership Recalculation Schedule: Define the start and end dates for membership recalculation.
  • Membership Recalculation Interval: Set the frequency of membership recalculation. Options include:
    • Once: The job runs a single time.
    • Minute Interval: The job runs "X" times every "Y" minutes, as specified. For example:
      • Iteration: 2, Interval: 24 minutes → Runs twice, with the second run 24 minutes after the first.
      • Run Indefinitely, Interval: 24 minutes → Runs every 24 minutes indefinitely.
    • Hour Interval: The job runs "X" times every "Y" hours, as specified. For example:
      • Iteration: 2, Interval: 24 hours → Runs twice, with the second run 24 hours after the first.
      • Run Indefinitely, Interval: 24 hours → Runs every 24 hours indefinitely.
    • Daily: The job runs once every "X" days at a designated time. For example:
      • Iteration: 2 → Runs twice, with the second run on the next day at the specified time.
      • Run Indefinitely → Runs daily at the designated time.

By configuring these schedules, administrators can ensure that hierarchy generation and membership recalculation jobs align with their organization’s operational needs, reducing manual intervention while keeping group memberships and structures up to date.

Workflow for Implementing Dynamic Hierarchies​

Implementing a Dynamic Hierarchy Policy involves a series of steps. The process begins with the configuration of the policy itself, including the selection of attributes, naming conventions, and directory placement. Once the policy is defined, the Dynamic Hierarchy Generation job is activated. This job scans the data in scope and identifies the groups or roles that need to be created or updated.

After the generation job has completed its run, the Dynamic Hierarchy Fulfillment job processes the queued actions. This job ensures that the groups and roles identified during the generation step are created or deleted as necessary. Only after these steps are complete should the Membership Recalculation job be activated. This job evaluates current data to assign users to the appropriate groups or roles, ensuring that memberships are accurate and up-to-date.

Key Jobs in Dynamic Hierarchies​

The following jobs are used to implement and maintain Dynamic Hierarchies:

  • Dynamic Hierarchy Generation Job: Scans the data in scope to determine the groups, roles, or locations that need to be created, updated, or deleted, and populates the queue with required actions.
  • Dynamic Hierarchy Fulfillment Job: Processes the queued actions generated by the Generation Job, creating, deleting, or updating groups and roles as necessary.
  • Membership Recalculation Job: Evaluates the current data to determine group memberships, updating group memberships based on changes to attribute values.
  • Membership Inbox Processor Job: Processes the membership updates queued by the Membership Recalculation Job, ensuring users are added or removed from groups as needed.

It is important to note that the generation and membership jobs should not be activated simultaneously when a policy is first implemented. If membership recalculation runs before groups are created, it will not find any groups to populate, resulting in wasted processing cycles. Best practices recommend activating the generation job first, verifying its output, and then enabling membership recalculation.

Special Features and Advanced Configurations​

Dynamic Hierarchies include several advanced features to enhance their functionality. One such feature is the ability to delay the removal of users from groups when their data changes. For example, if an employee transitions from one department to another, the system can allow a coexistence period during which the user remains a member of both groups. This delay ensures continuity and minimizes disruptions during transitions.

Organization chart groups are another advanced feature. These groups are based on managerial relationships and can reflect both direct and dotted-line reporting structures. An optional setting allows these groups to be nested, creating a multi-level hierarchy that mirrors the organizational chart.

Dynamic Hierarchies also support the reuse of existing groups through the claim matching groups feature. If a group matching the naming convention already exists, the system can adopt it instead of creating a duplicate. Additionally, groups can be mail-enabled for integration with email systems like Microsoft Exchange.

Advanced Filtering with SQL Queries​

A powerful aspect of Dynamic Hierarchies is the ability to filter the data evaluated by policies using SQL-like queries. This feature allows administrators to target specific subsets of data when creating groups, roles, or locations. Filters can be applied to include or exclude data based on precise conditions, ensuring that only relevant attributes are used in policy execution. In the General section of the policy configuration you can enter an SQL clause into the "Inclusion Where Clause" section to filter the data.

For example, if you want to create departmental groups only for departments that include the word "sales," you can define a filter like this:

AND person.department LIKE '%sales%'

The clause that is entered will be contatenated to an existing where clause in a stored procedure at runtime. Therefore, the format should start with AND followed by the condition to be evaluated.

Troubleshooting and Best Practices​

To ensure successful implementation, it is critical to validate the accuracy of the data being used. Attributes such as department or location should be consistent and free of errors, as inaccuracies can result in incorrect group memberships. Monitoring the execution of jobs is also essential. Logs should be reviewed regularly to identify and resolve any errors that occur during processing.

Advanced filters should be tested to confirm that they include the intended data set. For example, SQL-like filters can be used to restrict the evaluation to specific departments or regions. Testing these filters beforehand helps avoid unintended results.

By following best practices and leveraging the full range of configuration options, organizations can maximize the benefits of Dynamic Hierarchies and ensure their group and role structures remain accurate and aligned with organizational goals.