Say, when an account has two separate multi-valued attributes (N and M number of values for each attribute respectively), exporting accounts on that source produces N + M − 1 rows for an account as if each multi-valued attribute is expanded independently, with the “other” attribute pinned to its first value during that pass.
Example - Active Directory (objectClass and memberOf):
Account jdoe has objectClass (4 values: top, person, organizationalPerson, user) and memberOf (3 values: CN=Sales,..., CN=VPN-Users,..., CN=AllStaff,...). These have no positional relationship at all, yet the export still produces 4 + 3 − 1 = 6 rows, including irrelevant pairings like (person, CN=Sales,...) that imply a relationship between an objectClass value and a specific group membership that doesn’t exist.
My questions would be:
Is this a known limitation in how ISC’s source export layer flattens accounts with more than one multi-valued attribute?
Is there a supported way to export multiple multi-valued attributes without this cross-pinning artifact (either kept fully independent, or genuinely paired by position when they are correlated)?
Could someone clarify and has already been aware of these observations?
The rows aren’t pairs. ISC stores each multi-valued attribute as its own list on the account and keeps no link between the values of different attributes. A CSV cell holds one value, so the export adds rows to fit each list and repeats the first value of the other attributes to fill the gaps. Grouping rows by native identity and taking the distinct values per column gives you back the account as ISC holds it.
To get the lists without that layout, use GET /v2026/accounts?filters=sourceId eq "<source id>". Each multi-valued attribute comes back as its own array, so objectClass and memberOf stay separate. If two attributes really are paired by position on the target system, ISC won’t keep the pairing, and you’d need to combine them into one attribute during aggregation (for example role|scope).
I haven’t seen the N + M − 1 layout documented, so I’m going by your description here. Which export produced it: the Export Accounts button on the source, or the Accounts report under Reports? If the layout differs between the two, the grouping advice may not fit.
Hello Varshini. This looks like a limitation of how Source Export flattens multiple multi-valued attributes into CSV rows, rather than a real relationship between the values.
objectClass and memberOf are separate multi-valued account attributes, and I do not see any documented positional relationship between values across two multi-valued attributes, or a Source Export setting that controls how they are paired during export. So values such as person appearing beside CN=Sales should not be interpreted as related, and I would treat the N + M - 1 pattern you observed as export behavior rather than a documented ISC rule.
If you need the account attributes without that CSV flattening, the cleaner option is the List Accounts API:
GET /accounts/v1?filters=sourceId eq "<sourceId>"
The API returns the aggregated account attributes in JSON, so you can process each multi-valued attribute independently and generate the CSV format you need.
If memberOf is configured as an entitlement attribute and you specifically need the account’s entitlements, you can also use:
GET /accounts/v1/{id}/entitlements
If two attributes genuinely have a positional relationship, I would not rely on Source Export to infer or preserve it across two separate multi-valued attributes. The relationship is better modeled as a single composite value before or during ingestion (for example a role|scope value), where the source or connector supports it.
So I do not see a Source Export configuration that removes this flattening behavior. Using the account or account-entitlement API and building the output yourself would be the safer approach.
This is a known behavior, cannot say bug. I couldn’t find any information why there is record/row for every entitlement user has instead it could have been a single record with array of entitlements in a single cell.
I just used it for some data analysis, but never I could use it as “Actual Accounts Report”
Believe you might not need all attributes in your report (depends on requirements)
Make use of API and parse it to CSV file as per your needs to get the greater flexibility.