Provides a detailed description of the parameters that must be set to control how the Succession subject area is loaded.
To control how the Succession subject area is loaded, you must consider the following parameters:
The succession hierarchy, which connects candidates for a job or position with the incumbents, may be impractically large if there are many incumbents in jobs that are connected with several candidates. You can control this using two data load parameters.
Succession plan data, which is refreshed incrementally if the succession plan is active. You can configure whether an incremental refresh should include both the recently—inactivated plans or a list of individually named plans.
Metrics that inform you whether candidates successfully replace incumbents who moved on. You can use data load parameters to determine whether replacement has actually occurred.
A detailed description of the data load parameters is available later in this topic.
Optional or Mandatory
This task is optional because, in a majority of instances, the default settings for these parameters may not need modification.
Applies to
All adaptors.
Dependencies
No dependencies.
Data Load Parameters
| Parameter Name | Description | Default Value |
|---|---|---|
|
Succession Hierarchy Parameters: |
||
|
Enable Succession Hierarchy |
Allows you to enable or disable the succession hierarchy. |
Enabled. |
|
Succession Single Incumbents Only |
When the number of incumbents for jobs or positions is large, with many candidates, this parameter prevents the hierarchy from becoming impractically large. In all other scenarios, this parameter value can be changed to allow multiple incumbents, thereby providing more accuracy when navigating the hierarchy. |
Single Incumbents Only |
|
Plan Success Parameters: |
||
|
Succession Plan Success Window |
Defines the amount of time taken for a succession replacement after the departure of an incumbent. The candidate is considered successful if they transfer into the same Job/Position/Supervisor as the incumbent prior to their departure. The dimensions that are used may be controlled by other parameters. |
One month |
|
Succession Match on Job/Position/Supervisor |
Controls the dimensions that are used to compare, and subsequently determine, whether a candidate has successfully replaced an incumbent. For example, for an INCUMBENT level plan where the incumbent has been terminated, a candidate is considered to successfully replace the incumbent if the candidate’s Job/Position/Supervisor is updated to match that of the incumbent. However, the updates must happen within a given time window before the incumbent’s termination. |
Yes |
|
Incremental Refresh Parameters: |
||
|
Succession Plan Refresh Window |
Refreshes succession plan data, such as, whether a candidate has replaced a departed incumbent, for the specified time interval. After that time lapses, the plan is made inactive. |
One month |
|
Succession Plan Refresh List |
A comma—separated list of named plans to refresh. If a plan is inactive for so long that it won’t be picked up by the refresh window, it can be refreshed by including it in this list. |
Empty list |
|
Records Retention Parameters |
||
|
Keep Period |
In facts that prune records that are older than a specified time period, this parameter defines the time window for which record history must be retained. However, to define a time window beyond which records are pruned, this parameter must be used along with the Number of Periods parameter. For example, setting Keep Period to Calendar Month, and Number of Periods to 12, will keep a rolling 12 month history in the fact. Older records will be automatically purged. A similar result can be obtained by setting Keep Period to Calendar Year and Number of Periods to 1. |
CAL_MONTH (Calendar Month) |
|
Number of Periods |
In facts that prune records that are older than a specified time period, this parameter defines the number of Keep Periods for which record history must be retained. To define a time window beyond which records are pruned, this parameter must be used along with the Keep Period parameter. For example, setting Keep Period to Calendar Month, and Number of Periods to 12, will keep a rolling 12 month history in the fact. Older records will be automatically purged. A similar result can be obtained by setting Keep Period to Calendar Year and Number of Periods to 1. This parameter can also be used in a similar fashion to Refresh Period to specify the time window for refreshing the fact table. For example, setting Refresh Period to Calendar Month and Number of Periods to 3 will cause the ETL processing to delete and reload the last 3 months of data in the fact table. |
12 |