Configuring the Onboard Person Approval Policy

This article explains how to configure the Approval policy for onboarding new individuals into the system. It covers scenarios where the ResourceID for a new person is not yet established (referred to as “resourceless”) and illustrates how RBAC approvers function in these conditions.

Overview

When onboarding a new person, the system may not always have the final resource ID immediately available. In such cases, the system enters a “resourceless” state, using placeholder values until the correct resource ID is assigned. During this state, the approval routing logic has specific requirements to ensure that the onboarding request is properly authorized.

Key Points:

• RBAC Approver Required: All approval workflows rely on RBAC-defined approvers.

• Resourceless Conditions: If no valid resource ID exists at the time of the request, the system defaults to global-level RBAC approvers.

• Transition to Resource-Based Approvals: Once the correct resource ID is assigned, approvals can be refined and routed at a more granular (item) level.

Approval Routing Logic

1. Resourceless Requests:
   At the initial stage of onboarding, a placeholder or “fake” resource ID is often generated. Until the correct resource ID is established:

   • Approvals are routed solely through global RBAC approvers.

   • This ensures that requests cannot proceed without authorization, even before the final resource type is confirmed.

2. Resource-Based Requests (Post-Assignment):
   After the resource ID is assigned, the system can leverage the resource type to determine appropriate RBAC approvers. At this point:

   • Approvals can be configured at a more granular, item-level basis if required.

   • Multiple items or roles can be onboarded simultaneously, each with its own approval logic, as long as the correct resource IDs are now available.

Required Configuration Parameters

To properly route approvals, certain data fields must be set in the onboarding request. These can be configured at either the global (business request) level or the item (individual record) level:

• request_data.target_resource_type_id:
  Identifies the resource type you are onboarding (e.g., a person record).

• request_data.additional_resource_id:
  Specifies the origin or organizational context, ensuring that the system can reference the correct scope and location for RBAC logic.

Example: If you are creating a person resource in a specific organizational unit, set these fields to direct the approval request to the RBAC approver(s) responsible for that unit.

Operations and Customization

• Operations (Create or Custom):
  While the most common operation is create, custom operations are also supported.
  Note: If you use a custom operation, verify that it aligns with resourceless logic and that the required fields (target_resource_type_id and additional_resource_id) are provided.

• Location and Organizational Constraints:
  The system supports location-based or organizationally relative references. For example, it can route approvals according to location hierarchies. However, other relative references (such as “manager-based” references) are generally not supported in this scenario. Always ensure that the additional_resource_id accurately reflects the organizational or location-based constraints.

Putting it All Together

Scenario:

1. An onboarding request is initiated for a new person, but no final ResourceID exists yet. A placeholder ID is assigned.

2. During this resourceless stage, the system routes the approval to a global-level RBAC approver.

3. Once global fulfillment processes assign the correct ResourceID, the system updates the request, enabling more granular routing. Future items in the same request can have their approvals determined by item-level RBAC logic if desired.

4. Administrators confirm that target_resource_type_id and additional_resource_id have been set, ensuring the approvers are correctly identified.