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
+13-13Lines changed: 13 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ ms.date: 13/11/2025
6
6
7
7
# SSSAdminProd user and server-side sync operations
8
8
9
-
This article provides an overview of the changes customers can expect and will observe when server-side sync transitions to a new identity to communicate with Dataverse.
9
+
This article provides an overview of the changes customers can expect when server-side sync transitions to a new identity to communicate with Dataverse.
10
10
11
11
## Symptoms
12
12
@@ -16,16 +16,16 @@ This article provides an overview of the changes customers can expect and will o
16
16
17
17
## Cause
18
18
19
-
Server-side sync is changing the the identity used for its operations against Dataverse. Historically, server-side sync would simply leverage the user named SYSTEM that all environments have. Moving forward, server-side sync operations will transition to use the '# SSSAdminProd' user. However, to preserve backward compatibility, the SYSTEM identity will still be leveraged for some key server-side sync operations. This is to ensure that customer dependencies built on this identity are not impacted by this change.
19
+
Server-side sync is changing the identity used for its operations against Dataverse. Historically, server-side sync would simply use the user named SYSTEM that all environments have. Moving forward, server-side sync operations will transition to use the '# SSSAdminProd' user. However, to preserve backward compatibility, the SYSTEM identity will still be used for some key server-side sync operations, which ensures that this change does not impact customer dependencies built around this identity.
20
20
21
-
These are the key differences you can expect:
21
+
The key differences customers can expect are:
22
22
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.
23
23
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.
24
24
3. The audit log entries for server-side sync operations that do not impersonate a system user will change from SYSTEM to '# SSSAdminProd'
25
25
26
-
Below are a few sample scenarios to demonstrate what is changing and what is not. This is not a comprehensive list of scenarios.
26
+
The following are a few sample scenarios to demonstrate what is changing and what is not (not a comprehensive list):
27
27
28
-
### Scenario 1: an email in 'Pending Send' state is picked up by server-side sync, sent out, and moved to 'Sent' state through a 'SetState' operation. A synchronous workflow runs on email update to create a contact using the calling identity
28
+
### 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
29
30
30
|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|
31
31
|-|-|-|-|-|-|-|-|
@@ -39,7 +39,7 @@ Below are a few sample scenarios to demonstrate what is changing and what is not
### Scenario 3: an email is automatically tracked into Dynamics, for which server-side sync uses the DeliverIncoming SDK message. A synchronous plug-in runs on email create to create a contact using the calling identity
42
+
### Scenario 3: an email is automatically tracked into Dynamics, for which server-side sync uses the DeliverIncoming SDK message. A plug-in runs synchronously on email creation to create a contact using the calling identity
43
43
44
44
|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|
45
45
|-|-|-|-|-|-|-|-|
@@ -53,14 +53,14 @@ Below are a few sample scenarios to demonstrate what is changing and what is not
### Scenario 5: a task is tracked into Dynamics by server-side sync, which impersonates the actual user. A synchronous workflow runs on task create to create a contact using the calling identity
56
+
### 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
57
57
58
58
|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|
### Scenario 6: an appointment is tracked into Dynamics through server-side sync by a mailbox belonging to a user that is different from the appointment organizer, for which server-side sync does not use impersonation. A synchronous workflow runs on appointment create to create a contact using the calling identity
63
+
### Scenario 6: an appointment is tracked into Dynamics through server-side sync. The tracking mailbox belongs to a user that is different from the appointment organizer, so which server-side sync does not use impersonation. A synchronous workflow runs on appointment create to create a contact using the calling identity
64
64
65
65
|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|
66
66
|-|-|-|-|-|-|-|-|-|-|
@@ -69,25 +69,25 @@ Below are a few sample scenarios to demonstrate what is changing and what is not
69
69
70
70
## Resolution
71
71
72
-
No action should be required, server-side sync would continue functioning as normal after the transition.
72
+
No action should be required. Server-side sync would continue functioning as normal after the transition.
73
73
74
74
## FAQ
75
75
76
76
### 1. When will this transition take place?
77
77
78
-
This is currently planned to happen somewhere between November 2025 and March 2026.
78
+
This transition is currently planned to happen somewhere between November 2025 and March 2026.
79
79
80
80
### 2. Can I opt out of it?
81
81
82
82
There is no way to opt out of this change, but you should contact support if anything breaks after transition.
83
83
84
-
### 3. Moving forward, can we build dependencies (in the form of customizations, processes, etc.) around the fact that server-side sync operations are performed by '# SSSAdminProd'?
84
+
### 3. Moving forward, can we build dependencies (in the form of customizations, processes, etc.) around the fact that server-side sync performs its operations using '# SSSAdminProd'?
85
85
86
86
No. Much like the identity is changing now, it is also subject to changing again in the future, so any such dependencies could break.
87
87
88
-
### 4. We have built dependencies or processes around the identities that show up in the audit log or the delegate auditing fields when operations are performed by server-side sync. What should we do?
88
+
### 4. We built dependencies or processes around the identities that show up in the audit log or the delegate auditing fields when operations are performed by server-side sync. These identities are now changing. What should we do?
89
89
90
-
As these identities can and will be changing, we we advise against building dependencies around observations and assumptions about how the system behaves at a particular point in time, and instead refer to publicly documented system behaviors.
90
+
As these identities can and will be changing, 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.
91
91
92
92
### 5. We are not using server-side sync. Why is this user present? Can we disable it?
0 commit comments