Hello Experts,
Is there any way to get the entitlements who has the 0 members.
I have tried with below search query attribute:“memberOf” AND identityCount<1 but getting wrong results.
Thanks
Niket T
Hello Niket,
identityCount isn’t a searchable field on the entitlement index, so that part of your query isn’t evaluated as a count filter. It collapses to a loose match around memberOf, which is why the results look off. See Searchable Fields for what’s supported.
I don’t think zero member entitlements can be found in one Search query. Two ways that might work:
UI: Admin > Access Model > Entitlements, filter by the source, and sort/check the identity count column if it is available in your tenant.
API + Search: Pull the entitlements first:
GET /v2026/entitlements?filters=source.id eq "<sourceId>" and attribute eq "memberOf"
Then for each entitlement ID, run an identity-index Search:
@access(id:<entitlementId>)
If that returns zero identities, the entitlement currently has no members in Search. Using the entitlement ID instead of name/value avoids collisions when multiple entitlements share the same display name or similar values.
Also make sure entitlement aggregation and account aggregation have run recently on the source, otherwise the entitlement list or membership data may be stale and give false zeros.
Hi @niketnova ,
Just wanted to add on to other suggestions, if you need you can generate a certification and do excel spreadsheet vlookup from the export of your entitlements to assess Identities directly provisioned to the role.
Hi @niketnova ,
That is simple, a query like below, make sure you add a filter to the entitlement or check on the entitlement tab in results
NOT identityCount:>0 AND source.name:"sourcename"
Let me know how its worked.
Thanks,
Hi Niket,
In SailPoint Identity Security Cloud, memberOf is not the right attribute for this use case.
To find entitlements with no assigned identities, try filtering on the entitlement identity count directly, for example:
identityCount:0
or
identityCount<=0
depending on the search context/UI.
Also make sure:
-
Identity and entitlement aggregations are up to date
-
The entitlement source supports membership counting properly
The incorrect results are likely coming from combining memberOf with identityCount, since memberOf is an account attribute rather than an entitlement-level searchable field.
Hello Siva,
I don’t think identityCount is a searchable field on the entitlement index. It is not listed in Searchable Fields for entitlements. The supported first-level fields are id, displayName, name, description, privileged, requestable, attribute, value, modified, synced, and tags.
Since identityCount isn’t recognized, NOT identityCount:>0 doesn’t actually filter anything, and the query effectively collapses to source.name:"..." returning every entitlement on that source regardless of membership. The 0 showing in the result column is the Tags column, not an identity count.
Let me test this on my tenant & share the results in a follow up.
Hello Rimon,
I couldn’t find identityCount listed as a searchable field on the entitlement index in Searchable Fields, so identityCount:0 and identityCount<=0 don’t actually filter on count. They get treated as free-text and the query collapses to whatever else is in it.
On memberOf being an account attribute: attribute:"memberOf" on the entitlement index is actually valid syntax. attribute is a first-level searchable field on entitlements, and memberOf is the source attribute name on those entitlements (typically AD groups). The memberOf portion of @niketnova original query wasn’t the issue. The identityCount<1 portion was.
Happy to be corrected if you are seeing different behavior in your tenant, but the docs & my testing both point the same way on identityCount.
I ran a quick test on my LAB ProjectBoard Source to see how it behaves on my end.
The query NOT identityCount:>0 AND source.name:"LAB ProjectBoard Source" returned ProjectBoard Auditor User in the results. When I opened that entitlement, the Identities tab showed 2 assigned identities (daniel.brooks and elena.park), and the Details page confirms it’s a group entitlement on that source.
So in my tenant, the query is also returning entitlements that have members, which lines up with identityCount not being indexed for entitlements. Screenshot attached for reference. Curious if you are seeing different behavior on your side
Nope its not working.
Yes. I am also seeing similar things in my tenant. saw many of the entitlements having the identities