ISE Web Service Aggregation Missing Some Accounts

Hello Team,

I’m facing following issue with a Web Service source in ISC.

We have a target system – NERM – that contains 4,118 accounts, but when we run an account aggregation, ISE is only bringing in ~ 4,111 accounts. It always missing ~7 - 10 accounts.

Here’s what I’ve already tried:

Reset Accounts and reran the aggregation

Ran aggregation with/without optimization.

Downloaded the account extract to verify if any records are missing mandatory attributes (like accountId/accountname) – all data looks clean

Earlier, we were using paging steps on the Paging tab

Later, we shifted to using beforeOperation and afterOperation rules for pagination. But both options did not resolve the issue.

Rules look correct and do not throw errors. I tried the same pagination logic via postman and it returns expected number of accounts.

I’ve captured the logs and analyzed. Seems aggregation process is correctly fetching all the accounts from target end. Correlation logic also verified.

Despite all this, ISC is consistently misses ~7 to 10 accounts in the aggregated result.

Has anyone faced a similar issue?

Any guidance or troubleshooting tips would be really appreciated.

Thanks!

Did you check if you are using any filter in the aggregation HTTP Operation? and how did you configure the pagination ?

2 Likes
  1. You need to check your API, if it is returning correct results using Postman before going to SailPoint.
  2. Often we see this mismatch in count because of Pagination misconfiguration
  3. Possibility of duplicate accounts, you need to check if there is any duplicates values for attribute you selected as AccountID in your Account Schema.

Its all configurations, nothing on SailPoint.

2 Likes

Hi Ramesh,

Are you still seeing this issue? Are you adding any query parameters to the request url besides limit and offset? Are yhe accounts that are missed consistently the same or is it random?

2 Likes

Thanks, everyone, for your valuable input. We have identified the actual root cause. In the target source, there are a few accounts with duplicate employee numbers, which we had configured as the account ID in ISC. As a result, during aggregation, those duplicate accounts were replaced, causing the count mismatch. We have fixed the data issue in the target and the issue is resolved.

This issue means the Account ID isn’t unique. If two target accounts share the same value for the attribute mapped as Account ID, ISC will treat them as the same account and the later one overwrites the earlier one — so the final count is always short by the number of duplicates.

Quick way to confirm: export the source list and run a duplicate check on the AccountID field you mapped in the schema. If duplicates exist, either (1) fix the source data, or (2) change AccountID mapping to a truly unique key (GUID / internal account key). Then Reset Accounts and re-aggregate.

2 Likes

Thanks Amr. That was the actual cause for the issue.

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.