Skip to main content

Configuring an Approval Flow Policy - A Practical Walkthru

EmpowerID Training: Creating an Approval Flow Policy

Overview: Requirements and Process Dependencies​

To successfully configure a functional approval flow policy in EmpowerID, it’s essential to understand the logical dependencies between each component. Approval flows rely on a hierarchical structure of steps and policies, where each layer builds upon the previous one.

The process begins by defining the individual approval steps, which represent discrete checkpoints requiring approval. Each step must include at least one approver resolver rule and an escalation policy. These steps must be defined before they can be used in a flow.

Once the steps are created, they are assembled into an approval policy that dictates the flow order and the logic that controls progression between steps. The steps must be sequenced correctly, with preceding step dependencies set to ensure that each approval is evaluated in order.

After the approval flow policy is defined and published, it is linked to an access request policy, which acts as the trigger. When users request access to resources like groups or roles, the associated access request policy determines which approval flow is initiated.

Along with these basic dependencies and process flow, consider fallbacks and auto-approvals, both of which are safeguards to ensure a seamless user experience. Fallbacks prevent approvals from stalling when no valid approvers are available, and auto-approvals streamline scenarios where the approver and requestor are the same individual.

The flow is only complete and operational when:

  • All approval steps are fully defined and published.
  • Resolver rules and fallbacks are in place.
  • The approval flow policy is created, steps are linked in order, and published.

Understanding and respecting these dependencies ensures that every access request is processed according to business logic and governance requirements.

This walkthrough provides step-by-step instructions for configuring a multi-step approval flow policy in EmpowerID using the web user interface. It demonstrates how to create and assign approval steps, define resolver rules, publish the configuration, and test the setup. Each section includes additional context to explain the choices being made during the configuration process.

Step 1: Define Approval Steps​

The first task is to create the approval steps that will be used in the approval flow. These define individual approval checkpoints in the process.

  1. Navigate to Approval Policies > Approval Steps
  2. Create a New Approval Step
    • Name: Security Team Approval
    • Display Name: Same as name
    • Description: Briefly describes the step for documentation
    • Type: Default (This means it will use the default step behavior)
    • Escalation Policy: Default Escalation Policy (This ensures that the step will escalate after a set time or conditions if no approver acts on it)

This step will be used to represent the security team's review after a line manager has approved a request. The scenario modeled in this walkthrough includes a review process where a group membership request must first be approved by the requestor's line manager, then validated by the security team for compliance, and finally confirmed by the group’s resource owner.

Step 2: Assign Resolver Rules to the Step​

Resolver rules determine who the approvers will be for this step. In this case, approvers are based on a management role, with a fallback person defined in case the role is empty or the person in the role is also the requestor.

  1. Open the Security Team Approval step in View One
  2. Assign a Static Approver:
    • Type: Static
    • Target: Management Role
    • Role: SSRS Security Administrator

This ensures that any user in this management role can approve requests requiring security validation.

  1. Define a Fallback Approver:
    • Type: Static Approver
    • Approver: Phil Gehringer

This is critical for cases where the management role has no members or if the only person in the role is the requestor. EmpowerID's step logic excludes requestors from approving their own requests, so fallback prevents approval bottlenecks.

  1. Save the resolver rules.

Step 3: Create the Approval Flow Policy​

The approval policy links the individual approval steps in the required sequence.

  1. Navigate to Approval Policies
  2. Create a New Approval Policy
    • Name: Line Manager, Security Team, Owner Approval
    • Save the policy

This is a placeholder or shell definition that you’ll populate with steps in the next section.

Step 4: Add Approval Steps to the Policy​

Each approval step must be added to the flow in the correct order. You can specify conditions under which certain approvers should be removed or steps auto-approved.

  1. Step 1: Line Manager Approval
    • Step: Select Line Manager Approval
    • Preceding Step: None (This is the first step)
    • Conditions:
      • Remove approver if initiator is also the target (self-approving)
      • Auto-approve if initiator is also the approver

This saves time and clicks in scenarios where the line manager is initiating the request for their own direct reports. EmpowerID automatically approves such steps to streamline the process.

  1. Step 2: Security Team Approval
    • Step: Select Security Team Approval
    • Preceding Step: Line Manager Approval
    • Conditions: Same as above

This ensures the security team only evaluates requests that have already been approved by a line manager, maintaining a proper approval chain.

  1. Step 3: Resource Owner Approval
    • Step: Select Resource Owner Approval
    • Preceding Step: Security Team Approval
    • Conditions: Same as above

The final layer of approval is given to the owner of the group, allowing for an authoritative last word before access is granted.

  1. Save and Publish each step.
  2. Publish the Approval Flow Policy

Reminder: Be sure to publish the Security Team Approval step first to make it available for use in the approval flow policy.

Step 5: Configure Access Request Policy​

An access request policy determines which approval flow is triggered when a user requests access to a group.

  1. Navigate to Low Code / No Code > Access Request Policies
  2. Create New Access Request Policy
    • Name: Security Team Approval Required
    • Display Name and Description: same
    • Approval Policy: Line Manager, Security Team, Owner Approval
    • Option: Selectable in UI (Allows end users to select it in the IAM Shop)
    • Save

Step 6: Prepare a Test Group​

To validate the configuration, select a group and configure it to use the access request policy.

  1. Navigate to Identity Administration > Groups
  2. Select a group (e.g., Acme Banking Newsletter)
    • Confirm it is published in the IAM Shop
    • Set eligible requestors (e.g., yourself and test contractor)
    • Assign the access request policy: Security Team Approval Required
    • Add an RBAC Owner (e.g., Lab Administrator)

All of these steps are necessary to make the group requestable and ensure it will follow the defined approval process.

Step 7: Run a Test​

To test the full workflow:

  1. Place yourself into the SSRS Security Administrator management role (for security team approval eligibility)
  2. Navigate to IAM Shop and request access to the test group on behalf of another eligible user
  3. Submit a justification and business request
  4. Observe the behavior:
    • Line Manager: Auto-approved if initiator is also the line manager
    • Security Team: Auto-approved if initiator is in the management role
    • Owner: Auto-approved if initiator is the owner

In the live demonstration, the requestor was all three approvers, which resulted in full auto-approval for each step. The logs showed each step executing in the correct sequence.

Final Notes​

This walkthrough illustrates how to create a robust and layered approval policy using EmpowerID’s configurable web interface. With fallback mechanisms, conditional auto-approvals, and role-based resolvers, the configuration ensures that requests are handled consistently and efficiently, even in edge cases where approvers overlap or are unavailable.