Entitlements "Select all" bulk update applies only to the first 50 items in large tenants

Feedback Bugs
,
1

What problem are you observing?

The bulk “Update Requestable Status” action on the Entitlements page doesn’t apply to the full selection in our production tenant when I use “Select all”.

In production, the result set (filtered to AD source) has 9,992 entitlements. I tick the header checkbox, click “Select all: 9,992 items”, and set Requestable. The toast says “50 entitlements are updating”, then “Success! 50 entitlements have been updated. It may take a few minutes for the changes to take effect.” Only 50 entitlements actually change. [Still 50 after 4 hours.]

In our sandbox tenant, the result set has about 700 entitlements. The same steps show the same “50 entitlements” toast, but all ~700 are updated.

That leaves two problems:

  1. With a large selection, only the current page of 50 is updated, and the UI still reports success. Admins have no sign that most of the selection was skipped.
  2. In both tenants, the toast count is the number of rows ticked on the current page, not the number of entitlements the action will update.

My guess, which I haven’t verified: the full selection is resolved in the background after “Select all” is clicked. With ~700 entitlements this finishes before the update starts. With ~10,000 it doesn’t, so only the first page is used. No way to test this, naturally.

Screenshots attached: the selection bar (“50 of 9,992 selected” / “Select all: 9,992 items”) and the toasts.

image
image388×265 10.3 KB

image
image346×145 18.4 KB

What is the correct behavior?

After “Select all: N items”, the action should apply to all N entitlements, whatever the tenant size. The confirmation should show N, not the number of rows on the current page. If the full set can’t be processed, the UI should show an error instead of a success message.

What product feature is this related to?

Identity Security Cloud: Admin > Access Model > Entitlements, bulk actions, “Update Requestable Status” with “Select all”.

What are the steps to reproduce the issue?

  1. Use a tenant with several thousand entitlements (reproduced with 9,992; does not reproduce with ~700).
  2. Go to Admin > Access Model > Entitlements.
  3. Tick the header checkbox. The bar shows “50 of N selected”.
  4. Click “Select all: N items”.
  5. Click Actions > Update Requestable Status, choose Requestable, and click Save.
  6. Note the toast count (50).
  7. Filter the list on Requestable and count the results. Only 50 have changed.

Do you have any other information about your environment that may help?

  • Browser: [Chrome/Edge]
  • Reproduced on [29/09/26], [01:00 pm UTC+2]
  • Workaround: calling POST /entitlements/bulk-update from a script in batches of 50 updates the full set.
2

Hello Pratyush. Thanks for sharing the details. I think there is something worth investigating here, although I would keep the exact cause open for now.

One thing that caught my attention is the 50. SailPoint’s Bulk Update Entitlements API supports updating /requestable and is limited to 50 entitlements per request (reference). That also lines up with your workaround using batches of 50.

image
image1834×694 63.6 KB

The sandbox result is interesting because the toast says 50, but ~700 eventually update. So the toast does not appear to represent the full number being processed. In production, you observed only 50 changing, but I do not think we can say yet that those are specifically the first-page 50.

I would compare DevTools > Network for the same action in both tenants. If this UI is using /entitlements/v1/bulk-update, that should help show whether the request behavior differs between sandbox and production.

3

Thanks Harish, agreed. That’s why I labeled the cause as a guess.

I captured DevTools in prod. After I click “Select all: 9,992 items” and save, the UI sends a single POST /v2026/entitlements/bulk-update with 50 IDs, which are the 50 rows on the current page. No further calls follow, and the UI still reports success.

So the “Select all” selection never reaches the bulk action. The limit is one request of 50, sent for the visible page only. Awkwardly, I can’t capture the behavior in Sbx anymore as the system is being used :dotted_line_face:

1 Like