Skip to main content

Understanding Approval Steps in EmpowerID

Approval Steps are modular components within Approval Policies that define stages in the approval process for IAM Shop access requests. Each step determines who reviews the request, under what conditions approval occurs automatically, and what actions execute when decisions are made. Steps can evaluate entire requests or enable item-level decisions, supporting multi-tiered approval strategies aligned with organizational governance requirements.

Approval Steps in Context​

Approval Steps are the building blocks of Approval Policies. When users submit access requests through EmpowerID workflows—whether from the IAM Shop, onboarding processes, or other business flows—these workflows generate Business Requests containing one or more Business Request Items. Approval Policies composed of Approval Steps determine the approval routing for these items.

Approval Steps are reusable components that can be included in multiple Approval Policies, allowing organizations to standardize approval logic across different access scenarios while maintaining flexibility for exceptions.

How Approval Policies Are Selected​

Understanding how EmpowerID determines which Approval Policy to apply is critical for configuring effective approval routing. The system uses a precedence hierarchy based on where policies are assigned:

Precedence Hierarchy​

EmpowerID evaluates approval policy assignments in the following order, from highest to lowest precedence:

  1. Item Type Action Level (Global Override)

    • Applies to all instances of a specific action type (e.g., "Add Person to Group")
    • Use when the same approval policy should apply regardless of which resource is being accessed
    • Overrides policies set at lower precedence levels

  2. Item Type Action + Access Request Policy (Conditional Override)

    • Applies to specific Item Type Action when combined with a particular Access Request Policy
    • Use for exceptions where certain resources require different approval logic
    • Example: High-security groups requiring additional approval steps beyond standard groups

  3. Access Request Policy (Default Behavior)

    • Applies to all resources assigned to the Access Request Policy
    • Used when no higher-precedence policy assignment exists
    • Provides baseline approval behavior for resources

Practical Example​

Consider a scenario where you want different approval flows for group membership requests:

  • Most groups: Line manager approval only → Configure at Access Request Policy level
  • High-security groups: Line manager + security team + owner approval → Create a special Access Request Policy with a more stringent Approval Policy
  • All "Remove from Group" actions: Auto-approve or skip approval → Configure at Item Type Action level to override all other policies

This precedence model provides flexibility to establish organization-wide standards while allowing targeted exceptions for sensitive resources or actions.

Figure: Approval policy precedence hierarchy determines which policy applies to a request

Key Concepts​

Publishing and Version Control​

Approval Steps operate in draft mode until published. Publishing activates a step for use in production workflows and creates a version snapshot. EmpowerID maintains this version for in-flight approvals while allowing new requests to use updated versions, enabling administrators to refine approval logic without disrupting active approval processes.

For example, if you modify an Approval Step's escalation timeframe from 48 hours to 24 hours and publish the change, requests currently awaiting approval continue using the 48-hour timeframe while new requests submitted after publication use the 24-hour setting.

Figure: Approval step lifecycle from draft to versioned use in policies

Resolver Rules and the Four-Eyes Principle​

The Four-Eyes Principle is a governance control requiring that individuals cannot approve their own access requests. Resolver Rules enforce this principle by determining who receives approval tasks based on organizational relationships and policies.

Resolver Rules can route approval tasks to:

  • The initiator's manager
  • The owner of the requested resource
  • Members of a specific role or management role
  • Custom logic based on attributes or business rules

The "Initiator Manager" resolver rule demonstrates Four-Eyes enforcement: when a user requests access, EmpowerID routes the approval task to the user's manager rather than allowing self-approval. If the manager is unavailable or the initiator has no manager defined, fallback approvers ensure requests are not blocked.

Figure: Resolver rules can enforce separation of duties by excluding initiators and targets from the approver pool

Fallback Approvers​

Fallback approvers provide contingency routing when the primary resolver rule produces no available approvers. For example, if an approval step requires the target person's line manager to approve, but that person has no manager defined in the system, the fallback approver receives the task instead.

Fallback approvers are particularly critical when primary approvers might be excluded due to Four-Eyes enforcement. If a management role has only one member and that member is requesting access for themselves, they will be excluded as an approver, and the fallback approver will receive the task.

Pre-Approved Groups​

Pre-approved groups define specific audiences of users for whom access should be automatically approved without requiring manual review. When a user in a pre-approved group is the target of a request, the approval step is automatically completed, streamlining the process for low-risk scenarios.

Step-Level Fulfillment and Escalation​

Approval Steps can execute workflows when approvers make decisions. This step-level fulfillment capability enables:

  • Immediate provisioning - Grant access as soon as a specific approval step completes, before the entire request workflow finishes
  • Rejection workflows - Execute cleanup or notification logic when requests are denied
  • Audit logging - Record approval decisions in external systems
  • Dynamic notifications - Alert stakeholders based on approval outcomes

Escalation Policies define how EmpowerID handles approval tasks that remain unaddressed beyond specified timeframes. Without escalation, approval tasks may remain indefinitely pending, blocking access requests. Escalation actions typically reassign tasks to backup approvers, notify managers, or automatically close steps based on organizational policy.

Item-Level Approval​

By default, approvers make a single decision that applies to all items in a request. When Item-Level Approval is enabled, approvers can accept or reject each item independently. This granular control is valuable when requests bundle multiple resources with different sensitivity levels, when approvers have authority over some requested items but not others, or when risk assessments vary by item type within the same request.

Figure: Comparison of step-level approval versus item-level approval behavior