@amithkumar1 -
AI-assisted response — researched with assistance from Claude and validated against official SailPoint connector documentation. All claims below are sourced to the linked ISC/connector docs. I have not yet tested this configuration in a tenant; noted explicitly where that matters.
Short answer: yes, ISC can own the approval logic. There are two documented ways to do it, and the per-Access-Profile duplication you’re seeing comes from being on the one Approval Flow that requires it.
1. Can the ServiceNow Catalog honor the ISC Access Profile approval config?
Yes — two documented options.
Option A — Approval Flow = “None” (this is the default setting)
Per Configuring Approval Flow:
“Select this option to use only ServiceNow for raising the request. The request is raised in Identity Security Cloud without any approval steps in ServiceNow. Approvals are then dependent on the Identity Security Cloud configuration.”
ServiceNow becomes a pure request front-end and every approval comes from your existing Access Profile configuration. Zero duplication. Trade-off: approvers act in the ISC UI / email, not in ServiceNow.
Option B — Approval Type = “Identity Security Cloud Workflow” (a rule type inside Configurable Approvals)
Per Approval Flexibility:
“Identity Security Cloud approval is used to initiate the approvals. The Approval request is received by users in ServiceNow. This approval rule will be initiated by Identity Security Cloud workflow after the access request is sent to Identity Security Cloud.”
This is the hybrid most people actually want: ISC stays the source of truth for approval logic, but approvers receive their task in ServiceNow.
Critical config detail for Option B — approvalsMustBeExternal must be set to false. From the same Configuring Approval Flow page:
“For the Identity Security Cloud WorkFlow approval type it is mandatory to set the approvalsMustBeExternal flag to false. The ServiceNow Service Catalog integration is dependent on Identity Security Cloud for approval details, and this will keep requests from getting auto approved.”
Note this is the inverse of the recommendation for every other approval type, where the docs suggest setting it to true.
2. Are separate approval workflows always required in ServiceNow?
No. Separate ServiceNow-side approval configuration is only required if you select Manager Approval or Configurable Approvals. Only three Approval Flow types exist: None, Manager Approval, and Configurable Approvals. Based on the screenshot in the original question, you’re on Configurable Approvals — which is why every Access Profile needs its own definition.
3. If you stay on Configurable Approvals — how to manage this at scale
The key structural point is that Approval Rules and Approval Definitions are separate, and rules are reusable:
Approval Rules define how to resolve an approver. Use the ISC-derived types so the “who” resolves dynamically from ISC data at runtime instead of being hardcoded per profile:
- Identity Security Cloud Manager
- Identity Security Cloud Owner (Primary Owner)
- Identity Security Cloud Additional Owners
- Identity Security Cloud All Owners
- Identity Security Cloud Governance Group
- Identity Security Cloud Source Owner
- Identity Security Cloud App Owner
Each of these makes a live call to ISC to fetch the owner/manager/group and correlates the result to a local ServiceNow user. That means a single rule such as “ISC Owner Approval” works across your entire Access Profile catalog.
Approval Definitions bind rule(s) to an Access Object Name with an Order value for sequential levels. This is the part that still requires one record per Access Profile.
So the practical pattern is: build 3–5 reusable rules, then bulk-populate the definition records. These are standard ServiceNow tables, so use Import Sets or Update Sets driven from an export of your ISC Access Profiles rather than creating them by hand.
Documented constraints on these types:
- ISC All Owners is mutually exclusive with ISC Additional Owners and ISC Primary Owner within the same approval definition
- ISC Source Owner applies only to access objects of type Entitlement or Access Profile
- ISC App Owner applies only to Access Profiles
Access Object Name is string-matched at execution time, not at edit time — the docs warn “caution needs to be maintained to ensure an exact match.” Typos fail silently until a request actually runs
Three things worth planning around
The approvalsMustBeExternal trade-off. The docs recommend true for every flow except ISC Workflow, but Limiting External Access Requests warns:
“Only users with OrgAdmin can raise requests when the flag approvalsMustBeExternal is set to True. This option is not suggested when using the request catalog for a wider audience.”
If you need to protect the ISC UI without that restriction, the documented alternative on the same page is a workflow using the Access Request Dynamic Approver event trigger to evaluate request origin and cancel anything that didn’t come from the ServiceNow Service Catalog connector.
The fallback group doesn’t cover the ISC Workflow type. The SailPoint Access Governance Group catches requests where no approver resolves, but per Approval Flexibility: “default group and auto approval settings are not applicable for rule types ServiceNow Workflow, ServiceNow Flow, and Identity Security Cloud Workflow.” And if that group is empty or has no valid members, the requested item goes to Closed Incomplete as Request Cancelled with the approval Rejected.
Closed Incomplete overrides completed approvals. Also from Approval Flexibility: “If a requested item (RITM) is marked as Closed Incomplete at any time during its lifecycle, the approval field will be marked as Rejected even if all approvals are successfully completed, as per ServiceNow’s OOTB behavior.” Worth knowing before audit review.
Recommendation
If your approvers are willing to work in the ISC UI, switch Approval Flow to None and the duplication problem disappears entirely.
If approvers must stay in ServiceNow, use the Identity Security Cloud Workflow approval type with approvalsMustBeExternal = false. You’ll still need one Approval Definition record per Access Profile, but the approval decision logic lives only in ISC — which solves the “two places” maintenance concern even if the mapping rows remain.
What I validated, and what I didn’t
- Validated: every quoted statement above comes from the official SailPoint connector documentation pages linked below, retrieved directly.
- Not validated: I have not executed this configuration in a tenant. In particular, the exact runtime behavior of the ISC Workflow approval type and how it surfaces ISC-side approvals into ServiceNow should be confirmed in a sandbox before rollout.
- Version caveat: these pages cover the ISC (not IdentityIQ) Service Catalog connector. UI labels and available approval types differ across connector versions, so confirm against the version installed in your instance.
- I reviewed the Approval Flexibility page in targeted sections (approval types, definition fields, fallback behavior) rather than end to end, so there may be additional relevant detail on that page.
Sources
