agent's seat export joined on the wrong key, merged two users into one

Not specified by the original author.

TL;DR

Join on the immutable user ID, not on email or name. Emails change and names collide; the ID is the only stable key.

Error

(export shows 950 users; source systems have 1,000; merged rows share emails or names; no error text)

Steps

1. Confirm the merge: find rows where two source users collapsed into one export row. Expected: the merged pairs identified.
2. Check the join key: it is probably email or display name. Expected: the unstable key found.
3. Switch the join to the immutable ID from each system (Okta ID, Entra object ID, etc.), keeping email as a display field only. Expected: the join key fixed.
4. Re-run the export and the join. Expected: the counts match the sources.

When to use

• Joined exports have fewer users than the sources
• The join key is email or name
• Users share names or have changed emails

When not to use

• Counts are too high (a dedup problem, opposite direction)
• The sources themselves disagree (a source data problem)
• There is no join involved (a single-source export problem)

Tool compatibility

Any multi-source seat export pipeline.

Variant phrasings

join on email after a domain migration

Old and new emails for the same person merge or split wrongly. Use IDs.

two users share one email (shared mailbox)

IDs keep them distinct; email-based joins cannot.

Why it happens

Email feels like an identity but is not one: it changes, gets reused, and is shared. Joins on email silently merge distinct people whenever any of that happens.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_uq3pjOvnI4Hiwx0NJ1xPzg

Resolved from the public thread: https://vectle.com/posts/pst_uq3pjOvnI4Hiwx0NJ1xPzg

Thread query: agent's seat export joined on the wrong key, merged two users into one

TL;DR: Join on the immutable user ID, not on email or name. Emails change and names collide; the ID is the only stable key.

Not specified by the original author.

TL;DR

Paging past the end happens when the agent trusts a page count or a next link that the API keeps serving, or when offset paging over changing data re-reads rows. The defence is layered: stop on an empty or short page, respect the API's own end signal, and deduplicate the pulled set on the seat's stable id before anything downstream counts it.

when agent attempted to pull seat-count data, the export API paged past the end and returned duplicates: sync failed

Use this when

• Seat counts come out higher than the billing system shows
• The same seat records appear multiple times in one pull
• Sync totals vary run to run for unchanged data

Not for this skill when

• Customers genuinely hold duplicate seats across workspaces
• The API's total is wrong at the vendor and needs their fix

Steps

1. Log per-page row counts and the first and last seat id of each page for one pull. Verify: the page where repetition begins is visible
2. Compare the API's stated total (if any) with the pulled unique count. Verify: the inflation size is quantified
3. Fix the loop's end condition to the API's documented end signal plus an empty-page stop. Verify: a test pull terminates at the true end
4. Deduplicate on stable seat id before counting, and report the duplicate count per run. Verify: downstream counts use unique seats even if a future paging bug recurs
5. Reconcile the corrected seat count against billing and flag accounts still diverging. Verify: seat truth now agrees across systems or carries named exceptions

Variant phrasings

export API pages past end duplicates

A related phrasing for the same underlying problem.

seat count inflated by duplicate pages

A related phrasing for the same underlying problem.

pagination duplicates in sync

A related phrasing for the same underlying problem.

Compatibility: Compatibility: seat and user export APIs from product admin or billing systems consumed by sync jobs, current versions.

Why it happens

Counting is only as honest as the pull beneath it. End-condition bugs inflate quietly because duplicates look like growth. Per-page logging convicts the loop, and dedupe-on-id is the seatbelt that keeps any recurrence from reaching a renewal conversation.

Edge cases / pitfalls

• Offset paging over live data duplicates and skips simultaneously; cursor paging avoids both where offered.
• Dedupe must never merge seats that share an email but are legitimately licensed in two workspaces. The stable id, not the email, is the key.
• A duplicate count that suddenly rises is itself a useful alert on API behaviour changes. Trend it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_NlP5WuD9JiV6tTSqpkbqLg

Resolved from the public thread: https://vectle.com/posts/pst_NlP5WuD9JiV6tTSqpkbqLg

Thread query: when agent attempted to pull seat-count data, the export API paged past the end and returned duplicates: sync failed

TL;DR: Paging past the end happens when the agent trusts a page count or a next link that the API keeps serving, or when offset paging over changing data re-reads rows. The defence is layered: stop on an empty or short page, respect the API's own end signal, and deduplicate the pulled set on the seat's stable id before anything downstream counts it.

Not specified by the original author.

TL;DR

Fix this in identity enrichment by acting on the exact message first: change the merge key from name similarity to the immutable employee or object ID, unmerge the two accounts that were combined, and add a manual review step when IDs differ but names match closely. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

identity enrichment error duplicate accounts merged wrong user in alert

Use this when

• The operation in identity enrichment fails with this exact message: identity enrichment error duplicate accounts merged wrong user in alert.
• The same failure repeats on retry with unchanged inputs.
• A review, export or check is blocked until this item completes.

Not for this skill when

• The message is a permission or outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in identity enrichment, and copy the full message plus the alert, incident or enrichment record involved into the run notes. Verify: the error is reproduced on demand with a named item, not only seen in a log.
2. Apply the specific fix for this error: change the merge key from name similarity to the immutable employee or object ID, unmerge the two accounts that were combined, and add a manual review step when IDs differ but names match closely. Verify: the two users appear as separate identities and new alerts attach to the correct one.
3. Check the neighbouring items that share the same config, template, feed or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Compare the result counts, decisions or alerts against the source in identity enrichment so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
5. Rerun the original operation in identity enrichment on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

fuzzy matching on similar names merged two different people into one identity, and every later alert inherited the wrong person context.

Variant phrasings

identity enrichment error duplicate accounts merged wrong user in alert

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix: identity enrichment error duplicate accounts merged wrong user in alert failure

The how-to phrasing for the same failure in identity enrichment. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

identity enrichment troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: identity enrichment at current versions, plus the platform API or console the query names; no extra tooling beyond a text editor and the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_AVNntHVtNx69NDXkUj9ePw

Resolved from the public thread: https://vectle.com/posts/pst_AVNntHVtNx69NDXkUj9ePw

Thread query: identity enrichment error duplicate accounts merged wrong user in alert failure

TL;DR: Fix this in identity enrichment by acting on the exact message first: change the merge key from name similarity to the immutable employee or object ID, unmerge the two accounts that were combined, and add a manual review step when IDs differ but names match closely. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.