Skip to main content

Working with Approval Flow Policies

Overview​

Approval Flow Policies are a foundational component of EmpowerID's request management and governance framework. They define the approval routing, approver logic, escalation behavior, and decision-making conditions that apply when users submit requests through EmpowerID workflows—whether through the IAM Shop, onboarding flows, entitlement reviews, or other business processes.

In EmpowerID, requests for access, role assignment, or resource modification are always handled through structured workflows. These workflows generate Business Requests, which encapsulate one or more Business Request Items (individual access or resource change actions). Approval Flow Policies are then applied to these items to determine who must approve each action before fulfillment can occur.

What Do Approval Flow Policies Control?​

Approval Flow Policies:

  • Define one or more approval steps that must be completed before access or changes are granted.
  • Assign approval resolver rules to each step to dynamically determine the correct approvers.
  • Include fallback approvers to ensure coverage when primary approvers cannot be resolved.
  • Support escalation policies in case of inaction, reassigning or notifying alternate approvers.
  • Enforce Four-Eyes Principles by excluding initiators or access recipients from approving their own requests.
  • Allow pre-approval conditions for certain users or roles where access is considered low risk.
  • Support version control, allowing changes to be made and published without impacting in-flight requests.

Approval Flow Policies are tightly integrated with EmpowerID’s low-code workflows, access request policies, item type actions, and RBAC/PBAC architecture. As a result, they can be reused across a variety of access scenarios and enforced consistently across resources and request types.

How Approval Flow Policies Are Used​

Approval Flow Routing and component dependencies

When a user submits a request—for example, to be added to a group—the workflow engine:

  1. Generates a Business Request and one or more Business Request Items.
  2. Determines the Item Type Action for the request (e.g., "Add Account to Group").
  3. Locates the appropriate Approval Flow Policy based on a layered precedence model:
    • First, from the Item Type Action (global policy).
    • Then, from the Item Type Action + Access Request Policy (conditional override).
    • Lastly, from the Access Request Policy itself (default behavior).
  4. Applies the defined approval steps, each with its own resolver rule.
  5. Evaluates whether any of the steps require auto-approval, escalation, or fallback routing.
  6. Once all required approvals are collected, the request is marked for fulfillment by the associated workflow.

This model allows for a high degree of customization, such as:

  • Sending approvals to different individuals depending on the target resource or recipient.
  • Automatically approving access for low-risk users in specific roles or locations.
  • Re-evaluating approvers dynamically when business conditions change (e.g., a manager changes).
  • Controlling how approvers interact with the request—including editing access duration or assigning the approval to another individual.

Why Approval Flow Policies Matter​

Approval Flow Policies are critical to enforcing governance, accountability, and compliance across an enterprise identity system. They:

  • Ensure the right people review and authorize access or changes.
  • Provide full audit trails of who approved what, when, and why.
  • Reduce the burden on IT by automating request routing and approvals based on role and context.
  • Align with regulatory requirements like SOX, HIPAA, GDPR, and Zero Trust principles.
  • Support business flexibility by enabling exception handling, custom resolver rules, and policy overrides.

This training module introduces all the major components that make up an Approval Flow Policy, shows how they interact within workflows, and provides detailed configuration walkthroughs to help administrators and system architects create effective, scalable approval processes.

Approval Flow Policy​

An Approval Flow Policy in EmpowerID is a structured, configurable set of rules that governs how access requests are reviewed and approved before they can be fulfilled. It defines who must approve a business request, the order in which approvals must occur, and how approval tasks behave in various situations. These policies are used throughout EmpowerID's low-code/no-code workflows and play a central role in enforcing governance, compliance, and accountability.

Each Approval Flow Policy is composed of one or more approval steps, and each step uses a resolver rule to dynamically determine the correct approvers based on the request context. The policy can also specify fallback behavior, escalation conditions, auto-approval rules, and exclusion logic to prevent self-approval or violations of separation-of-duties.

Approval Flow Policy ViewOne Page

Where and How Approval Flow Policies Are Used​

Approval Flow Policies are applied during the execution of low-code workflows—such as those triggered by IAM Shop requests, onboarding actions, or recertification processes. These workflows generate a Business Request, and each individual Business Request Item (e.g., "Add person to group") looks to the associated Approval Flow Policy to determine the approval path.

The policy is referenced in different ways depending on the configuration:

  • Globally, at the Item Type Action level (e.g., for all "Add to Group" actions)
  • Conditionally, for specific Item Type Action + Access Request Policy combinations (e.g., exceptions for high-security groups)
  • Per Resource, through the Access Request Policy assigned to that resource

EmpowerID determines which policy to apply using a precedence hierarchy, which ensures flexible but deterministic behavior.

Policy Composition​

An Approval Flow Policy consists of:

  • Policy Definition:
    • Name, display name, description, and optional localization keys
  • Approval Steps:
    • Each step is defined separately and added to one or more policies
    • Steps can be sequenced using “parent step” logic to enforce multi-stage approvals
  • Escalation Policies:
    • Define what to do if no action is taken within a defined time period (e.g., escalate to another approver)
  • Behavioral Restrictions:
    • Prevent self-approval if the initiator is also the approver or target
    • Support “four-eyes” scenarios by removing individuals from the approval chain if they are involved in the request
  • Publishing & Versioning:
    • Approval Flow Policies are version-controlled; changes do not affect in-flight requests
    • Admins must publish a new version after making changes for them to take effect

Approval Step​

An Approval Step is the core building block of an Approval Flow Policy in EmpowerID. Each step represents a discrete stage in the approval process and is responsible for determining who needs to approve a specific access request or business action, when they need to do it, and what happens if they don't.

Approval steps are highly configurable and support conditional logic, escalation, auto-approval, delegation, and role-based resolution of approvers. Each step in the chain can execute independently or in sequence with others, enabling complex, multi-stage approval flows that reflect real-world business rules and compliance needs.

Approval Flow Step

Key Components of an Approval Step​

Each approval step includes the following key settings and behaviors:

  • Step Order and Dependency: Approval steps can be executed in parallel or sequentially. A step can optionally be assigned a Parent Step, which means it will only begin once the parent step has been completed. This is essential for multi-stage approvals like "Manager first, then Application Owner."

  • Resolver Rule: This is how the system determines who the approver should be. Resolver rules can dynamically evaluate context such as:

    • Request initiator's manager
    • Target user’s manager
    • Resource owner (RBAC or resource-specific)
    • Static approvers
    • Policy-based approvers (e.g., PBAC/RBAC approvers)
    • Geographical or organizational constraints (e.g., "approver must be in same country")

  • Exclusion Logic: You can configure rules to exclude the initiator, exclude the target, or remove someone who is both the approver and the initiator or target. This supports enforcement of four-eyes policies, SOX separation-of-duties, and more.

  • Fallback Approvers: If no approver is found via the resolver rule (e.g., a user doesn’t have a manager), you can configure a fallback. This might be a governance board, a static role, or even an administrative queue.

  • Pre-Approved Users: Some steps can be skipped altogether if the requestor is in a pre-approval list or meets pre-defined low-risk conditions. This supports automation of low-friction requests while still enforcing formal approvals for higher-risk ones.

  • Escalation Behavior: Approval steps can include escalation policies, which automatically escalate the approval to another user or role if the original approver fails to act within a defined window (e.g., 3 days). Escalations can:

    • Notify alternate approvers
    • Reassign the approval task
    • Trigger policy-defined workflows

  • Approver Permissions: Each approver can be granted different levels of authority for a given step, including:

    • Approve or deny
    • Modify access duration
    • Reassign approval task to someone else
    • Add additional approvers to the process
    • Comment and audit the request

  • Re-Evaluation During Approval: EmpowerID supports periodic recalculation of approvers during long-running approvals. This means if an approver leaves the company or changes roles mid-process, the system can replace them with the new manager or appropriate alternate automatically.

Best Practices Suggestions Regarding Approval Steps​

  • Always define a fallback to prevent approvals from stalling due to missing approvers.
  • Use parent steps only when sequential review is necessary; otherwise, steps can run in parallel for efficiency.
  • Avoid self-approval by leveraging exclusion rules.
  • Name steps clearly to describe their purpose and resolution logic (e.g., “Line Manager Approval”).
  • Reuse steps across multiple policies when possible to maintain consistency and reduce administrative overhead.

Approver Resolver Rules​

Approver Resolver Rules are one of the most powerful features in EmpowerID’s approval system. These rules determine who is assigned the approval task for each approval step in a policy. Rather than using static assignments, resolver rules dynamically calculate the correct approver(s) at runtime based on the request context, such as the person initiating the request, the target resource, or the access policy involved.

EmpowerID provides a wide variety of built-in resolver types to support complex, enterprise-grade approval routing. These resolver rules ensure that the right people are asked to review each request, based on their relationship to the requester, the resource, or organizational governance structures.

Approver Resolver Rules

Each resolver rule can also define:

  • Fallback assignees: For when no valid approver is found (e.g., manager field is blank)
  • Pre-approved audiences: For bypassing the step if the assignee qualifies for automatic approval
  • Auto-approval settings: Where no approver is resolved, the step may be skipped or completed automatically
  • Re-evaluation logic: To adjust for changes during long-running approval processes

Available Resolver Assignee Types​

Below is a detailed explanation of the built-in resolver types available for use within approval steps:

1. Initiator’s Manager​
  • Resolves the manager of the user who initiated the request.
  • Most commonly used in IAM Shop and onboarding scenarios.
  • Works well for general approval flows that require oversight of user actions by their direct supervisor.
  • Fallbacks may be necessary if the manager is not assigned or has left the company.

Example use case: A user requests access to an application. Their manager must approve the request as the first line of authorization.

2. Target Person’s Manager​
  • Resolves the manager of the user who is the recipient of the access.
  • Useful for delegated access scenarios (e.g., a manager requests access for someone on their team).
  • Ensures that the manager of the person actually receiving the access is part of the approval path.

Example use case: An IT support analyst requests mailbox access on behalf of a VP. The VP’s manager reviews and approves the request.

3. RBAC Owner​
  • Resolves the RBAC Owner.
    • These owners are the people who are specifically assigned the Access Manager access level for the resource. There can be multiple RBAC Owners of a resource

Example use case: Group or application owners are automatically involved in approving access to the resources they manage.

4. Responsible Party​

  • Resolves the Responsible Party of the target resource.

    • This owner is the single Person assigned to the resource as the primary person responsible for the existance of the resource. This owner is typically the person who can edit the meta-information (or attributes) of the resource and can assign ownership, and delete the resource. In the database, this owner is listed in the component record as the OwnerAssigneeID

Example use case: Group or application owners are automatically involved in approving access to the resources they manage.

5. Resource Owner​
  • Resolves the owner of the target resource.
  • In this context the resource owner resolves both the RBAC Owner and the Responsible Party in s single resolver rule.

    • RBAC Owner - These owners are the people who are specifically assigned the Access Manager access level for the resource. There can be multiple RBAC Owners of a resource

    • Responsible Party - This owner is the single Person assigned to the resource as the primary person responsible for the existance of the resource. This owner is typically the person who can edit the meta-information (or attributes) of the resource and can assign ownership, and delete the resource.

Example use case: Group or application owners are automatically involved in approving access to the resources they manage.

6. RBAC Approver​

  • RBAC Approver Resolver Rule​

The RBAC Approver resolver rule determines approvers by evaluating RBAC operation permissions configured on the resources involved in a business request. It does not simply look for owners or managers—it uses RBAC policy assignments to locate approvers who have been granted the authority to approve specific actions on specific types of resources.

This resolver dynamically finds approvers based on who has been granted Operational assignments (via RBAC operations) for the following components of the request:

RBAC Approver Resolver Rule

  • The Target Resource – the object being acted on (e.g., a group or application)
  • The Assignee – the person who will receive the access or change
  • The Additional Resource – an optional third resource of the transaction

The resolver references RBAC operation names defined for each Actionable Resource to determine who holds approval rights for the corresponding action.

Key Mechanism

Eaach business request item includes references to:

  • Target Resource – The resource directly impacted by the request
  • Assignee – The user receiving the role, permission, or membership
  • Associated Resource – An optional third resource involved in the request

The RBAC Approver resolver evaluates each of these entities to determine whether any assigned approver has the relevant RBAC operation permission that matches the action type being performed (e.g., ApproveGroupMembership, ApproveRoleAssignment).

This allows approver resolution to be highly contextual and dynamically based on EmpowerID’s RBAC model.

Example Scenario

A user is performing an Add Account To Group task but the approvals need to be routed based on the Person identity of the account. The business request includes:

  • Target Resource: The group to be assigned
  • Assignee: The user account that will be added
  • Added Resource: The joined person identity of the account

The action is mapped to the RBAC operation: "AddPersonToGroup" for the Additional Resource of the Person Identity

The resolver checks:

  • Does anyone have AddPersonToGroup on the Joined person identity of the account. If yes, those individuals are assigned to the approval step.

This approach allows organizations to delegate approval authority through RBAC policy, enabling highly scalable, dynamic, and policy-compliant workflows.

7. PBAC Approver​
  • Evaluates any PBAC Approvers based on the AppRight asignments of the approval appright on the target application.

Example use case: A contractor’s access to financial data is routed for extra review due to PBAC assignments to the requested app rights.

8. Previous Manager​
  • Used in mover or recertification workflows.
  • Resolves the former manager of a person who changed departments or locations.

Example use case: After a department transfer, the previous manager is prompted to recertify whether the employee still needs access to certain applications.

9. Static Approver​

Approver Resolver Rule - Static Approver

  • Assigns the step to a specific RBAC Actor Assignee and is selected Manually. RBAC Actor Options are:

    • Person
    • Management Role
    • Management Role Definition
    • Query Based Collection
    • Business Role and Location
    • Group

  • Ideal for escalation paths or specific resource governance scenarios.

Example use case: All access requests to VIP groups are routed to a named security officer.

10. Country- or Region-Based Approvers​
  • Resolves approvers based on the country or location of the target resource or user.
  • Enforces data residency or jurisdictional review policies.

Example use case: A user in Switzerland requests access to a file share. Only approvers in Switzerland are valid reviewers per GDPR rules.

11. Custom Resolver Rule (via Low-Code)​
  • Organizations can define custom resolver rules using EmpowerID’s low-code tools.
  • Supports integration with external systems or unique business logic.

Example use case: Approvers are pulled from a ServiceNow approval group or resolved based on time zone and seniority.

Fallbacks and Escalation in Resolver Rules​

All resolver rules support the configuration of fallback approvers, triggered when no valid primary approvers are found. Fallbacks are often assigned to:

  • Governance roles
  • Backup approver pools
  • Compliance teams

In addition, you can configure escalation triggers based on timeouts or inactivity—ensuring the request doesn't stall if the initial approver is unavailable or non-responsive.

Pre-Approved Users​

Resolver rules include an option to define a list of pre-approved users or roles. If the person initiating the request is pre-approved for a specific step, the approval is auto-granted. This helps streamline approvals for low-risk access while still enforcing policy-based routing for everyone else.

Item Type and Item Type Action​

Item Types and Item Type Actions are key components in the Business Request Item structure that define how EmpowerID processes and approves access-related Business Request Items.

These two components help classify what is being requested and how that request is processed, including the JSON template for the item type, which approval flow policies and fulfillment workflows apply.

Item Type​

Business Request Item Type

The Item Type identifies the type of object the request is being made against. Examples include:

  • Account Actions
  • Account Group Memberships
  • Management Role Assignment
  • Recertify Group Validity
  • Edit Group

When a business request item is created, the system stores a reference to the target object as the Target Resource, and the Item Type describes what kind of object that is and the JSON definition of the attributes and elements of the object.

Item Type Action​

Business Request Item Type Action

The Item Type Action defines the type of action being requested on the target object. It is always used in combination with the Item Type and serves two specific purposes:

  1. Assigning an Approval Flow Policy
  2. Identifying the Approval and Rejection Fulfillment Workflows to be Executed

In the workflow model of EmpowerID, the Protected Operation definition includes the assignment of the Item Type Action associated with the operation.

Each Item Type Action is used to tie specific transactions to appropriate approval and execution logic in the system.

Hierarchy of Approval Flow Policy Assignment​

EmpowerID uses a layered hierarchy to determine which Approval Flow Policy should apply to each item in a business request. This allows for both broad default policies and fine-grained overrides depending on the type of action, the target resource, and its configured Access Request Policy.

EmpowerID evaluates this hierarchy top-down, and as soon as a matching policy is found, that policy is applied—the evaluation does not continue to the lower levels.

1. Item Type Action-Level Policy (Highest Priority)​

The most global assignment is at the Item Type Action level. This allows organizations to enforce a particular approval policy for all requests of a specific action type, regardless of the resource being targeted or its own configuration. This is configured directly in the Item Type Action Definition.

  • Example: An organization may decide that any time someone requests to disable an account, it must go through a specific approval chain.
  • This policy is assigned directly to the Item Type Action in the system and overrides all others.

This level is ideal for defining strict approval requirements for sensitive actions that should always be reviewed—regardless of where they originate.

2. Item Type Action + Access Request Policy Combination​

This is a more granular override, allowing an organization to specify an approval policy only when a specific action is performed on a resource that has a specific Access Request Policy assigned. This is configured through the ViewOne page of the item type action in the section entitled Special Approval Flow Rules per Access Request Policy

  • Example: You may not want all group memberships to go through a special approval, but for certain high-security groups that use a specific Access Request Policy, you want AddPersonToGroup requests to be handled differently.

This combination override allows flexibility in tailoring approval behavior for special cases without affecting the global behavior of the action itself.

3. Access Request Policy-Level Assignment (Default)​

If no override is found at the Item Type Action level or the Item Type Action + Access Request Policy level, EmpowerID uses the Approval Flow Policy assigned directly to the Access Request Policy on the resource.

  • This is the default and most common configuration.
  • Each requestable resource is assigned an Access Request Policy, and that policy links to the Approval Flow Policy to use for that resource’s requests.

This level provides straightforward and intuitive control over how approval is handled for different resources, without needing to define global overrides.

How EmpowerID Evaluates the Hierarchy​

The policy selection process follows this top-down order:

  1. Check if an Approval Flow Policy is assigned to the Item Type Action.
  2. If not found, check for a policy assigned to the Item Type Action + Access Request Policy combination.
  3. If still not found, fall back to the Approval Flow Policy assigned to the Access Request Policy.

Why This Matters​

Understanding this hierarchy allows system administrators to:

  • Set global approval rules for high-risk actions.
  • Create exceptions for special resources or request types.
  • Control policy precedence explicitly through configuration.
  • Avoid unintentional overrides by knowing which level takes effect.

The structure provides the right balance of default behavior for simplicity and override capabilities for precision governance.

Business Request Types​

Business Request Type

A Business Request Type in EmpowerID defines the overall context, behavior, and processing logic for a business request. It acts as a container that links together approval policies, fulfillment workflows, and optional features such as expiration timeouts or integration touchpoints.

Business Request Types are a required component in EmpowerID’s access request architecture and are used across various request scenarios, including self-service requests, automated provisioning, delegated access, and access recertification.

Purpose of Business Request Types​

Business Request Types serve several key functions:

  • Define the overall purpose for the business request (e.g., access request, onboarding, recertification)
  • Assign a top-level Approval Flow Policy that governs approvals at the top level request as a whole
  • Assign a Fulfillment Workflow if required to fulfill a request-level action (such as onboarding a resource)
  • Optionally define expiration settings and external integration routing
  • Support request tracking and classification for reporting and audit purposes

Examples of Business Request Types​

Common Business Request Types configured in EmpowerID include:

  • IT Shop: Used for access requests submitted through the IAM Shop
  • Onboard a Management Role: Used for new user creation and entitlement assignment
  • Recertification: Used when access must be re-approved after a user changes departments or roles

Each type applies specific behaviors tailored to the request scenario. For example, onboarding requests may involve initial resource provisioning, while recertification requests focus on aggregating recertification items related to a main subject (such as the group or person)

Approval and Fulfillment Linkage​

Business Request Types link directly to:

  • An Approval Flow Policy, which defines how the request as a whole should be routed and approved
  • A Fulfillment Workflow, which defines how the request-level approved request is executed

These assignments apply at the request level and complement the item-level approval policies configured for each business request item.

This separation allows for flexible configuration, where individual actions within a request may follow their own approval logic, while the overall request still flows through a consistent fulfillment process.

Integration and External Fulfillment​

In more advanced implementations, Business Request Types can be configured to route fulfillment to external systems, such as ITSM or workflow engines. This may include:

  • Sending approved requests to ServiceNow for execution
  • Routing provisioning actions to separate fulfillment workflows

This integration flexibility allows EmpowerID to serve as a centralized decision and approval engine while extending fulfillment to existing enterprise platforms.

Approval Step Configuration for the Four-Eyes Principle​

Configuration for 4-Eyes compliance

EmpowerID provides built-in support for enforcing the four-eyes principle, a control mechanism that ensures no individual can unilaterally approve their own access request or actions that directly affect them. This principle is critical in enforcing separation-of-duties, reducing risk, and complying with governance frameworks.

Within each Approval Step, administrators can configure conditional behaviors based on the relationship between the approver, the request initiator, and the target of the request. These behaviors are defined using dropdown selections, not checkboxes, and each condition allows you to select a system action to take when the condition is met.

Available Conditions and Actions​

EmpowerID offers three conditional evaluation options in every approval step, each with a corresponding action selector:

1. If Initiator is Approver​

This condition is evaluated when the same person who submitted the request also resolves as an approver for the current step.

Administrators can configure the system to perform one of the following actions:

  • Send for Approval – Keep the person in the list of approvers (default behavior)
  • Auto-Approve – Skip the approval step entirely if the approver equals the initiator
  • Remove from Approvers – Exclude the person from the approval list for this step

This condition helps prevent self-approval in scenarios where users would otherwise resolve as approvers due to ownership or management responsibilities.

2. If Approver is Target Person​

This condition is evaluated when the person receiving access or changes is also the approver.

Action options include:

  • Send for Approval – Keep the person in the list of approvers (default behavior)
  • Auto-Approve – Skip the approval step entirely if the approver equals the initiator
  • Remove from Approvers – Exclude the person from the approval list for this step

This protects against users approving access changes that directly affect them, particularly in delegated or automated request scenarios.

3. If Approver is Initiator and Target Person​

This is the most restrictive condition and is only matched when the same person is both the initiator and the target of the request, and also resolves as an approver.

Available actions:

  • Send for Approval – Keep the person in the list of approvers (default behavior)
  • Auto-Approve – Skip the approval step entirely if the approver equals the initiator
  • Remove from Approvers – Exclude the person from the approval list for this step

This condition is typically used to enforce the strictest form of the four-eyes principle: ensuring that no user can approve a request they submitted for themselves.

How EmpowerID Enforces the Logic​

When a request is evaluated:

  1. The system resolves the approver(s) based on the resolver rule assigned to the step.
  2. It then checks each resolved approver against the configured conditions.
  3. For any approver that matches a condition, the system applies the selected action.

If an approver is removed and no other approvers remain, the system can escalate the request or apply fallback logic (depending on the configuration of the approval step and escalation policy).

Security and Compliance Alignment​

These options provide fine-grained control to support:

  • Separation-of-duties enforcement
  • Auditable approval chains
  • Automatic exclusion of conflicted approvers
  • Flexible behavior modeling, such as auto-approvals for low-risk requests or escalations for policy violations

By using these dropdown-based condition-action configurations, organizations can implement strong internal controls without requiring custom development or manual oversight.

Publishing and Version Control​

Approval Flow Policies in EmpowerID are version-controlled, ensuring that any changes made to an existing policy do not impact requests that are already in progress. This versioning model provides both stability and flexibility—allowing you to update approval logic while preserving the integrity of active workflows.

Whenever an Approval Flow Policy is modified—whether you’re adding or removing steps, updating resolver rules, or changing escalation behavior—those edits are saved as unpublished changes. At this stage, the policy remains in an editable state and is not yet active for use in new requests.

To activate the updated policy, you must publish it. Publishing creates a new version of the policy, which will then be used by all subsequent business requests. Importantly, publishing does not retroactively affect any in-flight approvals. Requests that were submitted under a previous version of the policy will continue using that version’s logic until they are completed.

This approach allows for confident policy changes in a live environment. You can refine approval chains, introduce new conditions, or switch resolver strategies without disrupting users or invalidating pending approvals.

Escalation Policies​

Escalation Policies

Escalation policies define automatic actions in case a configured time limit is exceeded for specific steps or global steps within an open business request. These policies can trigger various actions, such as sending notifications to the approver, the approver's manager, potential approvers' managers, or the initiator. Other actions include adding additional assignees to the business request or auto-closing the step or the entire request after a certain period if no action is taken.

Suppose you have an approval flow policy with multiple steps. You can create and map different escalation policies to each step. For example:

  • Notify the potential approver after one day
  • Add an assignee after two days
  • Auto-close the step with an "approved" status after three days

Escalation Policy​

The Approval Flow Escalation Policy is a predefined set of rules and actions that determine how to handle business request items that have not been acted upon within a specified timeframe. Once created, the policy can be added to multiple approval flow steps. The policy must be linked to a particular approval flow step to define what actions will be taken and after how many days.

Default Escalation Policy​

A default escalation policy is applied if no specific policy is configured for an approval step. The default escalation policy includes the following actions:

  1. Notify Potential Approver: After three (3) days of no action, send a notification to the potential approver.
  2. Notify Potential Approver Again: This action sends another notification if no action is taken within seven (7) days.

Escalation Policy Action​

The Approval Flow Model Escalation Policy Actions component details the actions to be executed under a policy for a specific request, including the duration before escalation, necessary supporting data, and the actions themselves, along with the sequence of escalations when multiple actions are present.

While creating the policy action, you can define:

  • The type of action
  • The timing (number of days after which the action should be triggered)

Escalation Action Types​

EmpowerID supports various out-of-the-box escalation action types to accommodate different escalation scenarios. Currently, the following action types are supported:

  • Notify: Triggers the notification system to alert subscribed users.
  • Add Assignee: Assign a new potential approver to the step. Allows the addition of any RBAC actor assignment as additional approvers.
  • Add Potential Approver Managers: Adds the managers of the current potential approvers as new approvers to the step.
  • Replace Assignees: Removes the current assignees and adds additional assignees. Allows the addition of any RBAC actor assignment.
  • Auto Close Step: Automatically sets the step’s status based on the approval decision configured in the escalation step. This may result in approving, rejecting, or moving forward as if the decision was made.
  • Auto Close Item: Closes the item and marks any open steps as skipped. Sets the status to the configured decision in the escalation step.

Escalate After X Days​

This setting defines the period (in days) after which an open step will trigger an escalation. The countdown begins from the start of the escalation period for the first escalation, and subsequent escalations are timed from the execution of the preceding one.