You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: support/power-platform/dataverse/email-exchange-synchronization/server-side-synchronization-new-admin-identity.md
ms.custom: sap:Email and Exchange Synchronization\Set up and configuration of server-side synchronizatio
7
7
---
8
8
9
-
# SSSAdminProd user and server-side sync operations
9
+
# Upcoming changes to the identity used by server-side sync for Dataverse communications
10
10
11
-
This article provides an overview of the changes customers can expect when server-side sync transitions to a new identity to communicate with Dataverse.
11
+
This article provides an overview of the upcoming change to the identity used by server-side sync for Dataverse communications. It includes a detailed list of the changes you can expect to see once the new identity is in use, as well as example scenarios comparing record fields before and after the switch.
12
12
13
-
## Symptoms
13
+
## Expected changes
14
14
15
-
> - A new system user named '# SSSAdminProd' is present in Dynamics 365
16
-
> - Some operations performed by server-side sync show up as being performed by '# SSSAdminProd' instead of SYSTEM in the audit logs
17
-
> - Some records created or updated by server-side sync have the '# SSSAdminProd' system user in the delegate auditing fields, such as "Created By (delegate)" and "Modified By (delegate)"
15
+
Server-side sync is changing the identity used for communications with Dataverse. Previously, server-side sync used the `SYSTEM` identity that all environments have. Server-side sync operations will transition to using the `# SSSAdminProd` identity moving forward. This transition is currently planned to happen between November 2025 and March 2026.
18
16
19
-
## Cause
17
+
> [!IMPORTANT]
18
+
> To preserve backward compatibility, the `SYSTEM` identity will still be used for some key server-side sync operations. This approach ensures that the identity transition doesn't impact customers that have build dependencies around the `SYSTEM` identity.
20
19
21
-
Server-side sync is changing the identity used for its operations against Dataverse. Historically, server-side sync would use the user named SYSTEM that all environments have. Server-side sync operations will transition to use the '# SSSAdminProd' user moving forward. However, to preserve backward compatibility, the SYSTEM identity will still be used for some key server-side sync operations, which ensures that this change doesn't impact customer dependencies built around this identity.
20
+
The key differences you can expect to see after the identity transition are:
22
21
23
-
The key differences customers can expect are:
24
-
1. For records created or updated by server-side sync, the delegate auditing fields "Created By (delegate)" and "Mofieid By (delegate)" will start showing the '# SSSAdminProd' user instead of being empty. The content of the "Created By" and "Modified By" fields remains unchanged.
25
-
2. For records created by synchronous customizations (such as workflows or plug-ins) running upon server-side sync operations and using the calling identity, the "Created By (delegate)" field will start showing the '# SSSAdminProd' user instead of being empty.
26
-
3. The audit log entries for server-side sync operations that don't impersonate a system user will change from SYSTEM to '# SSSAdminProd'
22
+
- A new system user named `# SSSAdminProd` is present in Dynamics 365.
23
+
- The audit log entries for server-side sync operations that don't impersonate a system user show as being performed by `# SSSAdminProd`instead of `SYSTEM`.
24
+
- For records created or updated by server-side sync, the delegate auditing fields _Created By (delegate)_ and _Modified By (delegate)_ show `# SSSAdminProd`instead of being empty. The content of the _Created By_ and _Modified By_ fields remains unchanged.
25
+
- For records created by synchronous customizations, such as workflows or plug-ins, that run upon server-side sync operations and use the calling identity, the _Created By (delegate)_ field shows `# SSSAdminProd` instead of being empty.
27
26
28
-
The following are a few sample scenarios to demonstrate what is changing and what isn't (not a comprehensive list):
27
+
## Example scenarios
29
28
30
-
### Scenario 1: server-side sync picks up an email in 'Pending Send' state, sends it out, and moves it to 'Sent' state through a 'SetState' operation. A synchronous workflow runs on email update to create a contact using the calling identity
29
+
The following example scenarios demonstrate which record fields will be changing. This is not a comprehensive list:
31
30
32
-
|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|
### Server-side sync picks up an email in 'Pending Send' state, sends it out, and then moves it to 'Sent' state through a 'SetState' operation. A synchronous workflow runs on email updates to create a contact using the calling identity.
36
32
37
-
### Scenario 2: an email is automatically tracked into Dynamics. A synchronous workflow runs on email create to create a contact using the calling identity
33
+
| 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 |
| Before | SYSTEM |**Empty**|**SYSTEM**| SYSTEM | SYSTEM |**Empty**| SYSTEM |
36
+
| After | SYSTEM |**# SSSAdminProd**|**# SSSAdminProd**| SYSTEM | SYSTEM |**# SSSAdminProd**| SYSTEM |
38
37
39
-
|Scenario|Email Created By|Email Created By (delegate)|Email Mofieid By|Email Modified By (delegate)|Email audit log identity|Contact owner|Contact Created By|Contact Created By (delegate)|Contact audit log identity|
### An email is automatically tracked into Dynamics. A synchronous workflow runs on email creation to create a contact by using the calling identity.
43
39
44
-
### Scenario 3: an email is automatically tracked into Dynamics. A plug-in runs synchronously on email creation to create a contact using the calling identity
40
+
| 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 |
| Before | SYSTEM |**SYSTEM**| SYSTEM |**SYSTEM**|**SYSTEM**| SYSTEM | SYSTEM |**Empty**| SYSTEM |
43
+
| After | SYSTEM |**# SSSAdminProd**| SYSTEM |**# SSSAdminProd**|**# SSSAdminProd**| SYSTEM | SYSTEM |**# SSSAdminProd**| SYSTEM |
45
44
46
-
|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|
### An email is automatically tracked into Dynamics. A plug-in runs synchronously on email creation to create a contact by using the calling identity.
50
46
51
-
### Scenario 4: an email is manually tracked into Dynamics. A synchronous workflow runs on email create to create a contact using the calling identity
47
+
| 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 |
| Before | SYSTEM |**SYSTEM**|**SYSTEM**| SYSTEM | SYSTEM |**Empty**| SYSTEM |
50
+
| After | SYSTEM |**# SSSAdminProd**|**# SSSAdminProd**| SYSTEM | SYSTEM |**# SSSAdminProd**| SYSTEM |
52
51
53
-
|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|
### An email is manually tracked into Dynamics. A synchronous workflow runs on email creation to create a contact by using the calling identity.
57
53
58
-
### Scenario 5: server-side sync tracks a task into Dynamics while impersonating the actual user. A synchronous workflow runs on task create to create a contact using the calling identity
54
+
| 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 |
| Before | SYSTEM |**SYSTEM**|**SYSTEM**| SYSTEM | SYSTEM |**Empty**| SYSTEM |
57
+
| After | SYSTEM |**# SSSAdminProd**|**# SSSAdminProd**| SYSTEM | SYSTEM |**# SSSAdminProd**| SYSTEM |
59
58
60
-
|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|
### 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.
64
60
65
-
### Scenario 6: an appointment is tracked into Dynamics through server-side sync. The tracking mailbox belongs to a user that's different from the appointment organizer, so server-side sync doesn't use impersonation. A synchronous workflow runs on appointment create to create a contact using the calling identity
61
+
| 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 |
| Before | User |**Empty**| User |**Empty**| User | User | User |**Empty**| User |
64
+
| After | User |**# SSSAdminProd**| User |**# SSSAdminProd**| User | User | User |**# SSSAdminProd**| User |
66
65
67
-
|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|
### Server-side sync tracks an appointment into Dynamics. The tracking mailbox belongs to a user that's different from the appointment organizer, so server-side sync doesn't use impersonation. A synchronous workflow runs on appointment create to create a contact by using the calling identity.
71
67
72
-
## Resolution
68
+
| 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 |
| Before | SYSTEM |**Empty**| SYSTEM |**Empty**|**SYSTEM**| SYSTEM | SYSTEM | Empty | SYSTEM |
71
+
| After | SYSTEM |**# SSSAdminProd**| SYSTEM |**# SSSAdminProd**|**# SSSAdminProd**| SYSTEM | SYSTEM | Empty | SYSTEM |
73
72
74
-
No action should be required. Server-side sync would continue functioning as normal after the transition.
73
+
## FAQs
75
74
76
-
##FAQ
75
+
### Can I opt out of it?
77
76
78
-
### 1. When will this transition take place?
77
+
You can't opt out of this change, but you should contact support if you experience any issues after the transition.
79
78
80
-
This transition is currently planned to happen somewhere between November 2025 and March 2026.
79
+
### 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?
81
80
82
-
### 2. Can I opt out of it?
81
+
No, the new identity is also subject to potential change in the future. Any dependencies built on the `# SSSAdminProd` identity could break.
83
82
84
-
There's no way to opt out of this change, but you should contact support if anything breaks after transition.
83
+
### We built dependencies or processes around the identities that show up 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?
85
84
86
-
### 3. In the future, can we build dependencies (in the form of customizations, processes, etc.) around the fact that server-side sync performs its operations using the '# SSSAdminProd' user?
85
+
As these identities can change in the future, only build dependencies on the publicly documented system behavior rather than observed system behaviors.
87
86
88
-
No. Much like the identity is changing now, it's also subject to changing again in the future, so any such dependencies could break.
87
+
### We're not using server-side sync. Why is this user present? Can we disable it?
89
88
90
-
### 4. We built dependencies or processes around the identities that show up 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?
91
-
92
-
As these identities can change, we advise against building dependencies around observations and assumptions about how the system behaves at a particular point in time. Instead, refer to publicly documented system behaviors.
93
-
94
-
### 5. We're not using server-side sync. Why is this user present? Can we disable it?
95
-
96
-
The user is present basically for all Dynamics environments, regardless of whether they're currently using server-side sync or not. We advise against fiddling with this system user in any way. Its presence shouldn't cause any trouble.
89
+
The new identity is present for almost every Dynamics environment, regardless of whether you're currently using server-side sync or not. Don't change system identities in any way.
0 commit comments