Skip to main content

Understanding Resourceless Approval Workflows for Person Onboarding

When onboarding new individuals into EmpowerID, a unique challenge arises: how should approval workflows function when the person's final ResourceID is not yet established? This article explains the concept of resourceless approval workflows and how they ensure proper authorization during the transitional period of person onboarding.

Understanding resourceless approval workflows enables administrators to:

  • Recognize when and why resourceless approval routing occurs
  • Configure workflows to handle the resourceless state appropriately
  • Ensure approval continuity during person provisioning
  • Troubleshoot approval routing issues during onboarding

The Resourceless State​

What Creates a Resourceless Condition​

During person onboarding, EmpowerID may not have the final ResourceID immediately available when approval routing must occur. The ResourceID is typically assigned during or after the person object is created in the identity store, but approval workflows may need to evaluate before this step completes.

In these cases, the system enters a resourceless state, using placeholder values until the actual ResourceID is assigned. This is not an error condition but a designed transitional stage that allows onboarding workflows to proceed without waiting for resource creation to complete.

Why Resourceless Approval Logic Is Necessary​

All approval workflows in EmpowerID rely on RBAC-defined approvers. Traditional RBAC routing depends on the person's resource context—attributes like department, location, or organizational unit that determine which approvers have authority to review the request.

Without a ResourceID, that context isn't yet available. The approval system cannot determine which department-level or location-level approvers should review the request because the person hasn't been associated with those organizational structures yet.

The resourceless approval model solves this by routing approvals through global fallback approvers until the final resource information becomes available. This ensures that approval requirements are enforced even during the transitional provisioning period.

note

Resourceless approval routing functions like routing a package to a central distribution hub before the final delivery address is confirmed. The approval proceeds through global oversight while the system establishes the person's identity and organizational context.

How Resourceless Approval Routing Works​

Resourceless approval workflows follow a two-stage routing pattern that adapts as identity information becomes available.

Visual Workflow​

The diagram below illustrates how EmpowerID routes approval requests during resourceless onboarding:

Stage 1: Global-Level Approval for Resourceless Requests​

When no valid ResourceID exists at the time approval routing occurs:

  • The system generates a placeholder ResourceID to maintain referential integrity
  • Approvals are routed exclusively to global RBAC approvers—approvers with organization-wide authority rather than department-specific or location-specific permissions

Global approvers typically include HR leadership, identity governance administrators, or other roles with broad oversight responsibility. This routing ensures that no onboarding request proceeds without proper authorization, even when specific organizational context is not yet available.

Stage 2: Transition to Resource-Based Approvals​

Once the person's ResourceID is assigned and organizational context is established:

  • EmpowerID re-evaluates pending approval steps
  • Routing logic shifts to item-level RBAC approvers based on the person's attributes—department, location, cost center, or other organizational dimensions
  • Multiple items in the same onboarding request can follow different approval paths based on granular RBAC policies

This transition from global to specific routing happens automatically as the person's identity and organizational context become available in the system.

Required Configuration Fields​

To properly route approvals through both stages, onboarding workflows must provide specific fields that inform the approval engine about resource type and organizational context.

Field Structure​

When configuring onboarding workflows—whether through the workflow designer, custom operations, or API integration—include the following fields in the request payload:

{
  "request_data": {
    "target_resource_type_id": "[ID of resource type, e.g. Person]",
    "additional_resource_id": "[ID of org unit or context]"
  }
}

Field Definitions​

FieldPurposeExample Values
target_resource_type_idIdentifies the type of resource being onboarded. For person onboarding, this is the ResourceType GUID for "Person" objects.Person ResourceType GUID
additional_resource_idSpecifies the organizational context for RBAC logic. This determines which organizational unit, location, or cost center the person will be associated with, enabling proper approval routing once the ResourceID is assigned.Organizational Unit GUID, Location GUID

Why These Fields Matter​

During resourceless approval (Stage 1):

  • target_resource_type_id informs the approval engine what type of resource is being created, enabling it to apply the correct approval policies
  • additional_resource_id provides organizational context that will be used for routing once the ResourceID is established

After resource assignment (Stage 2):

  • These fields enable the approval engine to shift from global routing to context-aware routing based on the person's organizational placement
Configuration Requirement

If target_resource_type_id and additional_resource_id are not set correctly in the onboarding workflow, approval routing will fail to transition from global to context-specific approvers. Verify these fields are populated in workflow configurations and test onboarding scenarios to confirm proper routing behavior.

Verifying Field Configuration​

Administrators can verify that these fields are configured correctly by:

  1. Workflow Testing: Submit a test onboarding request and review the Business Request approval routing
  2. Approval Step Review: Check which approvers receive the approval task—global approvers during resourceless stage, specific approvers after resource assignment
  3. Audit Logs: Review approval routing logs to confirm field values are populated and routing logic executed as expected

Supported Workflow Operations​

Resourceless approval logic applies to different types of person onboarding operations:

Create Person (Default)

The standard person creation workflow supports resourceless approval by default. When a new person is provisioned and approval is required before identity store creation, the workflow automatically uses resourceless approval routing.

Custom Onboarding Operations

Organizations may implement custom onboarding workflows that include additional provisioning steps, data validation, or integration with external systems. When building custom onboarding workflows:

  • Ensure the workflow includes target_resource_type_id and additional_resource_id in the approval request
  • Configure the workflow to handle the resourceless state appropriately—allowing global approval routing before resource creation completes
  • Test custom workflows to verify that approval routing transitions correctly from global to context-specific approvers

Custom operations that do not follow resourceless approval patterns may experience routing failures or delays when ResourceIDs are not immediately available.

Organizational Context and Approval Routing​

Location-Based and Organizational Approvals​

Resourceless approval workflows support location-based and organizational unit-based approval routing through the additional_resource_id field. This field specifies the organizational context that will be associated with the person once their ResourceID is assigned.

For example:

  • If additional_resource_id references the "Sales - North America" organizational unit, approval routing will include approvers with RBAC permissions for that organizational unit once the person's ResourceID is established
  • If additional_resource_id references a specific location, location-based approval policies will apply after resource assignment

Manager-Based Approval Limitation​

Manager-based approval references are not supported in resourceless workflows because the manager relationship depends on the person's ResourceID being established. During the resourceless state, the person does not yet exist as a resource in the identity store, so manager hierarchies cannot be resolved.

Organizations requiring manager approval for person onboarding should:

  • Use location-based or organizational unit-based approval routing during the resourceless stage
  • Configure approval policies to include manager approval as an item-level step after the person's ResourceID is assigned and manager relationships are established

Resourceless Workflow Example​

The following example illustrates how resourceless approval routing works in a typical person onboarding scenario:

Scenario: HR initiates onboarding for a new employee in the Sales - EMEA organizational unit. The onboarding workflow requires approval before creating the person in Active Directory.

  1. Request Initiation: HR submits the onboarding request through the IAM Shop. The workflow includes target_resource_type_id (Person) and additional_resource_id (Sales - EMEA OU GUID), but no ResourceID exists yet because the person hasn't been created.

  2. Resourceless Approval Routing: The approval engine recognizes the resourceless state and routes the approval to global RBAC approvers—in this case, the VP of HR who has organization-wide onboarding approval authority.

  3. Global Approval: The VP of HR reviews the request and approves the onboarding. The workflow proceeds to create the person in Active Directory.

  4. Resource Assignment: The person creation operation completes, and EmpowerID assigns a ResourceID to the new person. The person is associated with the Sales - EMEA organizational unit based on additional_resource_id.

  5. Context-Specific Routing (If Additional Items Exist): If the onboarding request includes additional items—such as assigning specific roles or granting application access—these items now route to EMEA-specific approvers based on the person's established organizational context.

  6. Verification: The administrator reviews audit logs to confirm that initial approval routed to global approvers and subsequent item approvals (if any) routed to context-specific approvers based on the Sales - EMEA organizational unit.

Key Design Principles​

Security Through Consistent Authorization​

Resourceless approval ensures that onboarding workflows never bypass RBAC approval logic—even when identity details are incomplete. Global fallback approvers provide oversight during the resourceless state, maintaining approval requirements throughout the provisioning process.

Workflow Continuity​

This model allows onboarding to begin immediately without waiting for identity store provisioning to complete. Organizations can initiate approval processes in parallel with resource creation, reducing onboarding time while maintaining governance controls.

Context-Aware Evolution​

Once full identity context is available, approval logic dynamically shifts from global to specific routing. This evolution maintains both agility (allowing work to proceed during provisioning) and precision (applying context-specific policies once information is available).

Configuring Global Fallback Approvers​

To support resourceless approval routing, organizations must configure global RBAC approvers who have authority to approve onboarding requests before organizational context is established.

Global approvers are typically configured through:

  1. Management Role Assignments: Assign HR leadership, identity governance administrators, or compliance officers to Management Roles with global onboarding approval permissions
  2. RBAC Policy Configuration: Ensure RBAC policies include global-level approval rules for person creation operations
  3. Approval Flow Policies: Configure approval flow policies to route resourceless onboarding requests to designated global approvers

Administrators should regularly review global approver assignments to ensure appropriate personnel have authority to approve onboarding requests and that approval responsibilities align with organizational governance requirements.