# ISC keeps retrying provisioning of entitlements on every identity refresh for an old access request that is no longer valid (plan shows source=Rule, assignment=true, jitClassificationSnapshotCaptured=true)

**URL:** <https://developer.sailpoint.com/discuss/t/isc-keeps-retrying-provisioning-of-entitlements-on-every-identity-refresh-for-an-old-access-request-that-is-no-longer-valid-plan-shows-source-rule-assignment-true-jitclassificationsnapshotcaptured-true/228377>\
**Category:** SHF Discussion and Questions\
**Tags:** access-requests, provisioning, sailpoint-identity-security, identity-security-cloud\
**Created:** [October 30, 2026, 2:28pm UTC](https://developer.sailpoint.com/discuss/t/isc-keeps-retrying-provisioning-of-entitlements-on-every-identity-refresh-for-an-old-access-request-that-is-no-longer-valid-plan-shows-source-rule-assignment-true-jitclassificationsnapshotcaptured-true/228377 "2026-10-30T14:28:17Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![ahmed119](https://avatars.discourse-cdn.com/v4/letter/a/d6d6ee/32.png) [@ahmed119](https://developer.sailpoint.com/discuss/u/ahmed119)\
**Post date:** [October 30, 2026, 2:28pm UTC](https://developer.sailpoint.com/discuss/t/isc-keeps-retrying-provisioning-of-entitlements-on-every-identity-refresh-for-an-old-access-request-that-is-no-longer-valid-plan-shows-source-rule-assignment-true-jitclassificationsnapshotcaptured-true/228377/1 "2026-10-30T14:28:18Z")

</div>

Hi all,

On every identity refresh, ISC sends a provisioning plan to a Web Services source (VA cluster) to add entitlements for one identity. We did request this access in the past, but that request is no longer valid and the access should not be provisioned now. ISC still keeps trying. I’m trying to find what generates the plan and how to stop it.

**What I see in the VA log (`ccg.log`)**

I attached a Before Operation Rule to the source’s Add Entitlement operation to print the plan. It shows the following, with names redacted:

JSON

```json
[ProvisioningPlan] :: {
  args={jitClassificationSnapshotCaptured=true, source=Rule},
  identity=<identity>,
  accounts=[{
    op=Modify,
    instance=null,
    application=<Web Services source>,
    attributes=[
      {args={assignment=true}, op=Add, name=groups, value=Risk Manager},
      {args={assignment=true}, op=Add, name=groups, value=Business User}
    ],
    nativeIdentity=<native id>
  }]
}

```

**Behavior**

- The same plan comes back on each identity refresh.
- The target account already exists, so this is a `Modify`, not a Create.
- The Add Entitlement call fails (`Provision Not Successful`). I assume ISC keeps retrying because the access is still missing.
- An access request was made for this identity in the past. It is no longer valid, and nobody wants the access provisioned now.
- I don’t know of an active workflow or manual assignment that would create this plan today.

**Questions**

1. Can an old access request that was approved or provisioned but failed keep being retried on refresh? If so, how do I see its state (pending, failed, or retrying) and cancel it?
2. What does `assignment=true` on each attribute mean? Does it mean the value comes from a role or access profile assignment, as opposed to a direct request?
3. What does `jitClassificationSnapshotCaptured=true` mean? I couldn’t find it in the documentation. Does it say anything about where the plan came from?
4. What’s the best way to trace what generated this plan for a specific identity? Is Events/Account Activity enough, or is there an API or search that shows the source of an entitlement assignment?
5. What’s the supported way to stop a failed or outdated provisioning plan from being retried on every refresh? Options I can think of are canceling the old request, removing the assignment, or clearing the pending operation. Which one is right?

---

<div class="post-metadata">

**Author:** ![iamnithesh](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/iamnithesh/32/42445_2.png) [@iamnithesh](https://developer.sailpoint.com/discuss/u/iamnithesh)\
**Post date:** [October 30, 2026, 4:31pm UTC](https://developer.sailpoint.com/discuss/t/isc-keeps-retrying-provisioning-of-entitlements-on-every-identity-refresh-for-an-old-access-request-that-is-no-longer-valid-plan-shows-source-rule-assignment-true-jitclassificationsnapshotcaptured-true/228377/2 "2026-10-30T16:31:59Z")

</div>

This is a known issue and tough one to clean up

[SaaS Solutions - Repeated account creation attempts for specific identity (“Sticky” entitlement)](https://sailpoint.service-now.com/kb/en/repeated-account-creation-attempts-for-specific-identity-sticky-entitlement?sys_kb_id=0d72079a47c45f143780fae5536d43f7&id=kb_article_view&sysparm_rank=1&sysparm_tsqueryId=0cde56a387230b90828143f5dabb353b&spa=1)