These changes take effect on **July 1, 2026**. Migration will be fully logged and communicated with at least 30 days' notice. Review the sections below and take any necessary action before the migration date.
Synerise is introducing a set of backward-incompatible changes to how user identifiers and UUIDs are handled. The changes align the platform with common industry standards, improve data consistency, and reduce accidental profile merges.
The logic described on this page already applies to all new workspaces created after **March 24, 2026**. Existing workspaces will be migrated on July 1, 2026.
## Summary of changes
| Area | What is changing |
|---|---|
| [Accent-sensitive identifiers](#accent-sensitive-identifiers) | Identifiers (`email`, `customId` / `custom_identify`) with diacritical characters are no longer normalized - they are treated as exact strings. |
| [Invalid identifiers](#fixing-invalid-identifiers) | Profiles with leading or trailing whitespace in identifiers are removed if a trimmed duplicate already exists; otherwise the identifier is trimmed automatically. |
| [UUID deduplication](#uuid-deduplication) | Duplicate UUIDs across profiles are resolved; uniqueness is enforced going forward. |
## Recommended actions before July 1, 2026
- [ ] **Accent-sensitive identifiers:** Audit your identifier data (`email`, `customId` / `custom_identify`) for accented or diacritical variants (for example, `jose@example.com` vs. `josé@example.com`). Ensure all your systems send identifiers in a consistent, exact form. If you believe your workspace may be affected, contact your Customer Success representative.
- [ ] **Whitespace in identifiers:** Verify that your integrations do not send identifiers with leading or trailing whitespace. To get a workspace-specific estimate of affected profiles, contact your Customer Success representative.
- [ ] **UUID deduplication:** No action is required in most cases. If you use custom UUID generation logic in your implementation, contact your Customer Success representative to assess potential impact.
## Accent-sensitive identifiers
### What is changing
Identifiers (`email`, `customId`/`custom_identify`) will no longer be normalized for diacritics or accents. Each identifier is treated as an exact string.
### Why
This change aligns the platform with common industry standards for identity systems. It prevents accidental merging of distinct users caused by normalization and improves correctness of user identity resolution, analytics accuracy, and privacy guarantees.
### Impact
Identifiers that differ only by accents or diacritical marks will be treated as separate profiles. No automatic normalization will occur. You must ensure consistent identifier usage across all systems.
### Examples
| Scenario | Before | After |
|---|---|---|
| Email with umlaut | `"muller@example.com"` = `"müller@example.com"` | `"muller@example.com"` ≠ `"müller@example.com"` |
| Email with accent | `"jose@example.com"` = `"josé@example.com"` | `"jose@example.com"` ≠ `"josé@example.com"` |
### Recommended actions
- Audit your identifier data for accented or diacritical variants.
- Ensure your systems send identifiers in a consistent form.
- Contact your Customer Success representative if you believe your workspace may be affected.
## Fixing invalid identifiers
### What is changing
Profiles with leading or trailing whitespace in their identifiers are handled as follows:
- If a profile with the same identifier in its **trimmed** form already exists, the whitespace variant is treated as a duplicate and **deleted**.
- If no corresponding trimmed profile exists, the identifier is **automatically trimmed** — the profile is not deleted.
### Why
Identifiers with whitespace are invalid by definition, cannot be reliably addressed via API or imports, and introduce inconsistencies in data processing. Removing them improves data hygiene and reduces edge-case complexity.
### Examples
#### Duplicate (profile will be deleted)
| | Before | After |
|---|---|---|
| Canonical profile | `"user@example.com"` | `"user@example.com"` — unchanged |
| Whitespace variant | `" user@example.com "` (note the leading and trailing spaces) | deleted |
#### Unique invalid identifier (profile will be trimmed, not deleted)
| | Before | After |
|---|---|---|
| Profile | `" user@example.com "` (note the leading and trailing spaces; no trimmed counterpart exists) | `"user@example.com"` — trimmed automatically |
## UUID deduplication
### What is changing
In a small fraction of cases, duplicate UUIDs exist across profiles. These rare occurrences will be resolved and UUID uniqueness will be enforced going forward.
### Why
Duplicate UUIDs can lead to ambiguous user identity assignment. Resolving conflicts improves system consistency, simplifies diagnostics, and reduces the risk of unpredictable routing of user data.
### Impact
- Some anonymous or unidentified profiles may be merged.
- In case of UUID conflicts between two identified profiles, the UUID is detached from one profile and replaced with a newly generated UUID.
- Device-stored UUIDs remain unchanged and continue to function as-is.
### Examples
#### Non-conflicting identifiers (profiles merged)
| Profile | Before | After |
|---|---|---|
| User A | `"john@example.com"` → UUID X | `"john@example.com"` → UUID X |
| Anonymous user B | UUID X | merged into User A |
#### Conflicting identifiers (UUID detached)
| Profile | Before | After |
|---|---|---|
| User A | `"john@example.com"` + UUID X | keeps UUID X |
| User B | `"alice@example.com"` + UUID X | UUID X replaced with newly generated UUID Y |
## Migration logging
All actions performed during migration (merges, deletions, and UUID changes) are fully logged and available on request.
## FAQ
**Can I request an estimate of impact for my workspace?**
Yes. For invalid identifiers and accent-sensitive identifier scale, contact your Customer Success representative. UUID conflict scale is expected to be marginal.
**Does this affect new workspaces?**
No. New workspaces created after March 24, 2026 already operate under the new rules.