|
| 1 | +--- |
| 2 | +title: Upcoming Changes to Server-Side Sync Identity in Dynamics |
| 3 | +description: Learn about the upcoming changes to the identity that's used by server-side sync in Dynamics 365, including effects on audit logs and delegate fields. |
| 4 | +ms.date: 11/13/2025 |
| 5 | +ms.reviewer: FERNAN.OVIEDO, v-shaywood |
| 6 | +ms.custom: sap:Email and Exchange Synchronization\Set up and configuration of server-side synchronizatio |
| 7 | +--- |
| 8 | + |
| 9 | +# Changes to server-side sync identity for Dataverse communications |
| 10 | + |
| 11 | +This article provides an overview of the upcoming changes to the identity that's used by server-side sync for Dataverse communications in Microsoft Dynamics 365. This article includes a detailed list of the changes that you can expect to see after the new identity is active. It also provides example scenarios that compare record fields before and after the switch. |
| 12 | + |
| 13 | +## Expected changes |
| 14 | + |
| 15 | +Server-side sync is changing the identity that's used for Dataverse communications. Previously, server-side sync used the `SYSTEM` identity that all environments have. Server-side sync operations are transitioning to using the `# SSSAdminProd` identity moving forward. This transition is currently planned to occur between November 2025 and March 2026. |
| 16 | + |
| 17 | +> [!IMPORTANT] |
| 18 | +> To preserve backward compatibility, the `SYSTEM` identity will continue to be used for some key server-side sync operations. This approach makes sure that the identity transition doesn't affect users that built dependencies around the `SYSTEM` identity. |
| 19 | +
|
| 20 | +The key differences that you can expect to see after the identity transition are: |
| 21 | + |
| 22 | +- A new Dynamics 365 system user that's named `# SSSAdminProd` is added. |
| 23 | +- The audit log entries for server-side sync operations that don't impersonate a system user are shown as performed by `# SSSAdminProd` instead of `SYSTEM`. |
| 24 | +- For records that are created or updated by server-side sync: |
| 25 | + - The delegate auditing fields _Created By (delegate)_ and _Modified By (delegate)_ now shows `# SSSAdminProd` instead of being empty. |
| 26 | + - The content of the _Created By_ and _Modified By_ fields remains unchanged. |
| 27 | +- For records that are created by synchronous customizations, such as workflows or plug-ins, and that run on server-side sync operations and use the calling identity: |
| 28 | + - The _Created By (delegate)_ field now shows `# SSSAdminProd` instead of being empty. |
| 29 | + |
| 30 | +## Example scenarios |
| 31 | + |
| 32 | +The following example scenarios demonstrate which record fields are changing. (This is not a comprehensive list.) |
| 33 | + |
| 34 | +#### Scenario 1 |
| 35 | + |
| 36 | +Server-side sync picks up an email message in 'Pending Send' state, sends it, and then moves it to the 'Sent' state through a 'SetState' operation. A synchronous workflow runs on email updates to create a contact by using the calling identity. |
| 37 | + |
| 38 | +| Scenario | Email Modified By | Email Modified By (delegate) | Email audit log identity | Contact owner | Contact Created By | Contact Created By (delegate) | Contact audit log identity | |
| 39 | +| -------- | ----------------- | ---------------------------- | ------------------------ | ------------- | ------------------ | ----------------------------- | -------------------------- | |
| 40 | +| Before | SYSTEM | **Empty** | **SYSTEM** | SYSTEM | SYSTEM | **Empty** | SYSTEM | |
| 41 | +| After | SYSTEM | **# SSSAdminProd** | **# SSSAdminProd** | SYSTEM | SYSTEM | **# SSSAdminProd** | SYSTEM | |
| 42 | + |
| 43 | +#### Scenario 2 |
| 44 | + |
| 45 | +An email message is automatically tracked into Dynamics. A synchronous workflow runs on email creation to create a contact by using the calling identity. |
| 46 | + |
| 47 | +| Scenario | Email Created By | Email Created By (delegate) | Email Modified By | Email Modified By (delegate) | Email audit log identity | Contact owner | Contact Created By | Contact Created By (delegate) | Contact audit log identity | |
| 48 | +| -------- | ---------------- | --------------------------- | ----------------- | ---------------------------- | ------------------------ | ------------- | ------------------ | ----------------------------- | -------------------------- | |
| 49 | +| Before | SYSTEM | **SYSTEM** | SYSTEM | **SYSTEM** | **SYSTEM** | SYSTEM | SYSTEM | **Empty** | SYSTEM | |
| 50 | +| After | SYSTEM | **# SSSAdminProd** | SYSTEM | **# SSSAdminProd** | **# SSSAdminProd** | SYSTEM | SYSTEM | **# SSSAdminProd** | SYSTEM | |
| 51 | + |
| 52 | +#### Scenario 3 |
| 53 | + |
| 54 | +An email message is automatically tracked into Dynamics. A plug-in runs synchronously on email creation to create a contact by using the calling identity. |
| 55 | + |
| 56 | +| Scenario | Email Created By | Email Created By (delegate) | Email audit log identity | Contact owner | Contact Created By | Contact Created By (delegate) | Contact audit log identity | |
| 57 | +| -------- | ---------------- | --------------------------- | ------------------------ | ------------- | ------------------ | ----------------------------- | -------------------------- | |
| 58 | +| Before | SYSTEM | **SYSTEM** | **SYSTEM** | SYSTEM | SYSTEM | **Empty** | SYSTEM | |
| 59 | +| After | SYSTEM | **# SSSAdminProd** | **# SSSAdminProd** | SYSTEM | SYSTEM | **# SSSAdminProd** | SYSTEM | |
| 60 | + |
| 61 | +#### Scenario 4 |
| 62 | + |
| 63 | +An email message is manually tracked into Dynamics. A synchronous workflow runs on email creation to create a contact by using the calling identity. |
| 64 | + |
| 65 | +| Scenario | Email Created By | Email Created By (delegate) | Email audit log identity | Contact owner | Contact Created By | Contact Created By (delegate) | Contact audit log identity | |
| 66 | +| -------- | ---------------- | --------------------------- | ------------------------ | ------------- | ------------------ | ----------------------------- | -------------------------- | |
| 67 | +| Before | SYSTEM | **SYSTEM** | **SYSTEM** | SYSTEM | SYSTEM | **Empty** | SYSTEM | |
| 68 | +| After | SYSTEM | **# SSSAdminProd** | **# SSSAdminProd** | SYSTEM | SYSTEM | **# SSSAdminProd** | SYSTEM | |
| 69 | + |
| 70 | +#### Scenario 5 |
| 71 | + |
| 72 | +Server-side sync tracks a task into Dynamics while impersonating the actual user. A synchronous workflow runs on task creation to create a contact by using the calling identity. |
| 73 | + |
| 74 | +| Scenario | Task Created By | Task Created By (delegate) | Task Modified By | Task Modified By (delegate) | Task audit log identity | Contact owner | Contact Created By | Contact Created By (delegate) | Contact audit log identity | |
| 75 | +| -------- | --------------- | -------------------------- | ---------------- | --------------------------- | ----------------------- | ------------- | ------------------ | ----------------------------- | -------------------------- | |
| 76 | +| Before | User | **Empty** | User | **Empty** | User | User | User | **Empty** | User | |
| 77 | +| After | User | **# SSSAdminProd** | User | **# SSSAdminProd** | User | User | User | **# SSSAdminProd** | User | |
| 78 | + |
| 79 | +#### Scenario 6 |
| 80 | + |
| 81 | +Server-side sync tracks an appointment into Dynamics. The tracking mailbox belongs to a user that's different from the appointment organizer. Therefore, server-side sync doesn't use impersonation. A synchronous workflow runs on appointment creation to create a contact by using the calling identity. |
| 82 | + |
| 83 | +| Scenario | Appointment Created By | Appointment Created By (delegate) | Appointment Modified By | Appointment Modified By (delegate) | Appointment audit log identity | Contact owner | Contact Created By | Contact Created By (delegate) | Contact audit log identity | |
| 84 | +| -------- | ---------------------- | --------------------------------- | ----------------------- | ---------------------------------- | ------------------------------ | ------------- | ------------------ | ----------------------------- | -------------------------- | |
| 85 | +| Before | SYSTEM | **Empty** | SYSTEM | **Empty** | **SYSTEM** | SYSTEM | SYSTEM | Empty | SYSTEM | |
| 86 | +| After | SYSTEM | **# SSSAdminProd** | SYSTEM | **# SSSAdminProd** | **# SSSAdminProd** | SYSTEM | SYSTEM | Empty | SYSTEM | |
| 87 | + |
| 88 | +## Frequently asked questions |
| 89 | + |
| 90 | +**Q1: Can I opt out of this change?** |
| 91 | + |
| 92 | +**A1:** You can't opt out of this change. However, you should contact Microsoft Support if you experience any issues after the transition. |
| 93 | + |
| 94 | +**Q2: In the future, can we build dependencies (in the form of customizations, processes, etc.) around the fact that server-side sync performs its operations by using the "# SSSAdminProd" user?** |
| 95 | + |
| 96 | +**A2:** No, the new identity is also subject to potential change in the future. Any dependencies that are built on the `# SSSAdminProd` identity could break. |
| 97 | + |
| 98 | +**Q3: We built dependencies or processes around the identities that appear in the audit log or the delegate auditing fields when server-side sync performs certain operations. These identities are now changing. What should we do?** |
| 99 | + |
| 100 | +**A3:** Because these identities can change in the future, we recommend that you build dependencies on only the publicly documented system behavior instead of observed system behaviors. For more information, see [Server-side synchronization](/power-platform/admin/server-side-synchronization) |
| 101 | + |
| 102 | +**Q4: We're not using server-side sync. Do we need this user? Can we disable it?** |
| 103 | + |
| 104 | +**A4:** The new identity exists for almost every Dynamics environment, regardless of whether you're currently using server-side sync. Don't change system identities in any way. |
0 commit comments