title: Approver Resolution category: Workflows & Automation tags: approver, resolution, manager, role-based, delegation priority: Normal
Approver Resolution
Approver Resolution is the process by which IdentityCenter determines who should approve a given workflow step. Rather than hardcoding individuals into every workflow, the system dynamically resolves approvers at runtime based on organizational data synced from Active Directory and configured business roles.
How Approver Resolution Works
When a workflow reaches an Approver node, the resolution engine:
- Reads the resolution method configured on the node
- Evaluates the method against the request context (requester, resource, attributes)
- Resolves one or more approvers
- If the primary approver cannot be found, applies fallback logic
- Notifies the resolved approver and waits for a decision
Resolution Methods
Direct Manager
The most common resolution method. The system reads the manager attribute from the requester's synced AD object and resolves it to the corresponding Person record in IdentityCenter.
| Property | Detail |
|---|---|
| Source | AD manager attribute (Distinguished Name) |
| Resolution | DN is matched to an Object, then linked to a Person record |
| Requirement | Manager must be synced and active in IdentityCenter |
| Fallback | If manager is missing or inactive, fallback rules apply |
Tip: Ensure your synchronization project includes a Manager Resolution step. This step resolves the
managerDN into a linkedManagerObjectId, which the approver resolution engine depends on. See Manager Resolution for details.
Skip-Level Manager
Resolves the manager of the requester's manager. This is useful when a request requires approval from someone higher in the hierarchy, or when the direct manager is the requester themselves (e.g., a manager requesting access for their own team).
| Property | Detail |
|---|---|
| Resolution | Resolve requester's manager, then resolve that manager's manager |
| Chain Depth | Configurable: 1 level (direct manager's manager) or N levels up |
| Fallback | If any link in the chain is missing, fallback rules apply |
Business Role
Assigns approval to any user who holds a specified business role in IdentityCenter. Business roles are organizational designations mapped to AD groups.
| Property | Detail |
|---|---|
| Role Selection | Choose from configured roles (e.g., CISO, Compliance Officer, IT Security Lead) |
| Multiple Members | If the role has multiple members, any one member can approve |
| Quorum | Optionally require a minimum number of approvals from role members |
For more on configuring roles, see Business Roles.
Department Head
Resolves the designated head of the requester's department. The department head is typically configured as a business role or identified via a specific title pattern.
| Property | Detail |
|---|---|
| Resolution | Match the requester's department attribute to a configured department head |
| Configuration | Department heads are mapped in Administration > Organization |
| Fallback | If no head is configured for the department, fallback rules apply |
Specific User
Hardcodes a named individual as the approver. Use sparingly -- this method does not adapt to organizational changes.
| Property | Detail |
|---|---|
| Selection | Choose a specific user from the directory |
| Use Case | Compliance Officer, a named external auditor, or a system owner |
| Risk | If the user leaves the organization, the workflow step will stall without a fallback |
Group-Based
Assigns approval to members of a specified AD group or IdentityCenter group. Any member of the group can approve the request.
| Property | Detail |
|---|---|
| Group Selection | Choose an AD group or IdentityCenter group |
| Any-of / All-of | Configure whether any single member can approve, or all must approve |
| Quorum | Optionally require a minimum number of approvals (e.g., 2 of 5 members) |
Resolution Priority
When multiple resolution methods could apply, the system evaluates them in this order:
| Priority | Method | Reason |
|---|---|---|
| 1 | Specific User | Explicit assignment always takes precedence |
| 2 | Business Role | Organizational role-based assignment |
| 3 | Department Head | Department-level authority |
| 4 | Direct Manager | Most common default |
| 5 | Skip-Level Manager | Used as escalation or for self-service manager requests |
| 6 | Group-Based | Broadest pool of potential approvers |
In practice, each Approver node is configured with a single primary method. The priority above applies when configuring fallback chains.
Delegation
Approvers can delegate their approval responsibility to another user when they are unavailable.
How Delegation Works
- An approver receives a workflow notification
- The approver clicks Delegate and selects a delegate from the directory
- The delegate receives a new notification and can approve or deny on behalf of the original approver
- The audit log records both the original approver and the delegate
Delegation Rules
| Rule | Description |
|---|---|
| Allow Delegation | Enable or disable delegation per Approver node |
| Delegation Depth | Maximum number of times a request can be re-delegated (default: 1) |
| Delegate Pool | Optionally restrict delegates to specific groups or roles |
| Audit Trail | All delegations are recorded with timestamps and justification |
Standing Delegations
Administrators can configure standing delegations for users who are on extended leave:
- Navigate to Administration > Delegations
- Click New Standing Delegation
- Select the Original Approver and the Delegate
- Set the Start Date and End Date
- All workflow approvals during that period are automatically routed to the delegate
Fallback Approvers
When the primary resolution method fails (e.g., the requester has no manager), the system applies fallback logic.
Fallback Chain
Configure a fallback chain on each Approver node:
| Step | Action | Example |
|---|---|---|
| 1 | Try primary resolution | Direct Manager |
| 2 | Try first fallback | Department Head |
| 3 | Try second fallback | Business Role: IT Security Lead |
| 4 | Final fallback | Specific User: System Administrator |
Common Fallback Scenarios
| Scenario | Primary Fails Because | Recommended Fallback |
|---|---|---|
| New employee | Manager not yet synced | Department Head or HR Manager |
| Top-level executive | No manager in AD | Board-designated approver or self-attestation |
| Orphaned account | No manager attribute | IT Security team group |
| Contractor | Manager is external | Sponsoring department head |
Tip: Always configure at least one fallback approver. Workflows without fallbacks will stall indefinitely when the primary method fails, potentially blocking access requests and causing SLA breaches.
Timeout and Escalation
When an approver does not respond within the configured timeout, the system escalates.
| Timeout Action | Description |
|---|---|
| Remind | Send a reminder notification to the current approver |
| Escalate | Move the approval to the next person in the escalation chain |
| Auto-Approve | Automatically approve the request (use with caution) |
| Auto-Deny | Automatically deny the request |
| Reassign | Move the approval to a fallback approver |
For full escalation configuration, see Escalation & SLA Tracking.
Manager Chain Resolution
IdentityCenter builds the full management chain from synced AD data:
Employee: Jane Smith
Manager: Bob Jones (Direct Manager)
Manager: Sarah Chen (Skip-Level / Director)
Manager: Mike Davis (VP)
Manager: Lisa Park (C-Suite)
The chain is resolved by following the ManagerObjectId links through the Objects table. This chain is used for:
- Direct Manager resolution (level 1)
- Skip-Level Manager resolution (level 2+)
- Escalation when an approver times out (escalate up the chain)
- Delegation validation (ensure delegates are not in the same reporting line when SoD is required)
Chain Resolution Requirements
| Requirement | Details |
|---|---|
| Sync must include manager | The sync project must map the manager attribute |
| Manager Resolution step | A Manager Resolution step must run to convert DNs to ObjectIds |
| Active accounts only | Disabled or deleted managers are skipped; the chain follows active accounts |
| Circular reference protection | The engine detects and breaks circular manager references |
Troubleshooting Approver Resolution
| Problem | Likely Cause | Resolution |
|---|---|---|
| No approver found | Manager attribute is empty in AD | Add a fallback approver or fix the AD data |
| Wrong approver assigned | Stale sync data | Run a synchronization and verify manager mappings |
| Workflow stalled | Approver left the organization | Configure standing delegation or enable timeout escalation |
| Multiple notifications sent | Group-based resolution with all-of mode | Verify the quorum setting and group membership |
| Delegate cannot approve | Delegation is disabled on the node | Enable delegation in the Approver node properties |
Best Practices
- Always configure fallbacks -- Every Approver node should have at least one fallback
- Keep manager data current -- Schedule frequent syncs to ensure manager attributes are accurate
- Use roles over specific users -- Business roles adapt automatically as personnel change
- Enable delegation -- Allow approvers to delegate when out of office
- Set reasonable timeouts -- 48-72 hours for standard requests; shorter for privileged access
- Audit resolution regularly -- Review the audit log to confirm approvers are being resolved correctly
Next Steps
- Workflow Designer -- Build workflows with Approver nodes
- Workflow Triggers -- Connect workflows to events and schedules
- Escalation & SLA Tracking -- Configure timeout and escalation behavior
- Business Roles -- Define roles used in approver resolution
- Manager Resolution -- How AD manager data is synced
- Lifecycle Management -- Policy-driven workflows and remediation