IIQ 8.5 + Accelerator Pack Retirement: How Are You Handling Native Role Approvals?

IdentityIQ (IIQ) IIQ Discussion and Questions
, ,
1

Which IIQ version are you inquiring about?

8.3 to 8.5

I am evaluating a move away from the Accelerator Pack (AP) as part of my IdentityIQ 8.5 planning and have hit what appears to be the biggest gap: role approvals.

What I’m seeing

  • Disabling AP for several applications (AD, CME, ShareWorks) has had no impact on approval or provisioning outcomes.
  • However, disabling AP for business roles causes approvals to default to the Role Owner rather than follow our existing approval chain.

Today, access requests are routed through an AP wrapper with approval patterns such as:

  • Manager
  • Manager + Level 1
  • Manager + Level 2
  • Parallel approvals
  • Alternate approvers
  • Location-based approvers
  • Rule-driven approvers (e.g., VP determination)

The Question

Has anyone successfully replaced AP-driven role approvals with a native IIQ approach?

Specifically:

  1. How are you routing role requests through Manager → Level 1 → Level 2 approvals?
  2. Did you implement this in LCM Provisioning, custom workflows, approval-assignment rules, or another approach?
  3. Are there native IIQ capabilities in 8.5 that we’re overlooking?
  4. Any lessons learned from fully retiring Accelerator Pack?

Our preliminary assessment is that application provisioning can move to native IIQ fairly easily, but role approval routing appears to be the major dependency.

Interested in hearing how others solved this, especially in environments with complex multi-step approval chains.

Thanks in advance.

2

Hey hey @hilaryb86,

Not sure but I would look at the native ApprovalAssignment rule within the LCM approval subprocess as the main extension point.

Rather than rebuilding the entire approval workflow, I would externalize the AP approval patterns into role metadata and use an ApprovalAssignment rule to resolve the required approvers and build the appropriate approval hierarchy.

I would pay particular attention to mixed requests, add/remove operations, approvalSet decision propagation, and notification arguments. Depending on the required behavior, approvalSplitPoint and nested approvals may also be relevant.

Before implementing the migration, I would trace an existing AP request to identify exactly where its approval logic is injected and compare the resulting approvers against the native workflow.

I can run some tests if anyone respond a solution. :t_rex: