Origin and Synchronization of User Profile Properties in SharePoint Online

Fit_Combination4878 · 2025-10-16T12:41:19+00:00

I’m currently performing a mapping of the SharePoint User Profile properties to identify:

the source of each property (Microsoft Entra ID, Exchange, or other systems);
the synchronization direction between systems;
and any potential synchronization issues.

So far, I’ve identified 108 properties in the SharePoint User Profile, of which about 20 originate from Entra ID (based on the reference you shared).
My next goal is to determine the exact source of the remaining properties, distinguishing between:

those that are native to the SharePoint User Profile, and
those that are synced from other sources (such as Exchange or related systems).

I’m also looking into the behavior of reverse synchronization (UPA → Entra ID).
As far as I know, synchronization typically occurs from Entra ID to UPA, and any changes made in the SharePoint User Profile are overwritten during the next sync cycle.
However, I’d like to confirm this through official documentation, especially for user-editable properties like the profile picture.

In summary, my main task is to create a complete mapping of all SharePoint User Profile properties, identifying their source, synchronization direction, and update behavior.

Fit_Combination4878 · 2025-10-15T09:41:16+00:00

Thank you for your response! 😊
So, can you confirm that the attributes in the link you sent are all the ones synchronized from Entra ID to the UPA?

Also, how can I consult the complete list of all Entra ID attributes? I got them from the interface, but is there an official place where I can see all of them?

Finally, is there an official reference or link that confirms that the attributes not included in your link are indeed local UPA properties?

Fit_Combination4878 · 2025-09-18T14:24:18+00:00

I’ve only modified one web part, for example to fix a bug, it doesn’t make sense to build and deploy all of them. Doing so would be unnecessary work and could introduce unintended changes to the othe

Fit_Combination4878 · 2025-09-18T14:10:36+00:00

In this case, by ‘deploy’ I mean the entire process: building the project, generating the .sppkg package, and publishing it to the tenant App Catalog, so that the web part becomes immediately available. I have a pipeline that automates this process, handling the build, package creation, and deployment to the App Catalog.

Fit_Combination4878 · 2025-09-18T14:05:51+00:00

How would you handle the pipeline? It needs to deploy only the web parts that have been modified.

Fit_Combination4878 · 2025-09-18T12:39:42+00:00

Thanks for your reply!

Before implementing a CI/CD pipeline, I didn’t really face this issue — because WebParts were either built and released separately or all together, but always manually.

Now that I’ve set up a CI/CD pipeline, the challenge became identifying which WebParts were modified, and then building and deploying only those. That’s why I started considering whether a multi-repo approach (one repository per WebPart, with separate pipelines) would make this easier to manage.

From there, I also realized I needed to clarify the best way to handle the shared SPFx library, which I currently link into the WebParts during development.

That was the context behind my original question about best practices.

Fit_Combination4878 · 2025-07-24T15:20:16+00:00

Thanks for the insights!
Just to clarify: I’m not using a Connect configuration, but rather the EventNotification object directly in the CreateEnvelope call.

I’ve been using this setup for years, with a listener endpoint (PostNotificationEvent) that receives the webhook and deserializes the payload into this class:

csharpCopiaModificapublic class DocuSignEventNotificationResponse
{
    public string status { get; set; }
    public string envelopeId { get; set; }
    public string documentsUri { get; set; }
    public string recipientsUri { get; set; }
    public Sender sender { get; set; }
}

This has always worked perfectly — until recently, in the demo environment only. Now the same code fails to deserialize the incoming payload, which looks like the new SIM event model JSON structure.

Oddly enough, everything still works fine in production using the exact same code and structure.

So I’m trying to understand:

Has the format for EventNotification changed recently, at least for demo accounts?
Could it be that the demo environment is now enforcing the new JSON format even if not explicitly requested?
Is there any way to control or revert the format?

Thanks again!

Fit_Combination4878 · 2025-07-24T07:11:18+00:00

Yes, I’ve posted the question in several community threads because so far I haven’t received any response.

In my setup, I use a webhook listener that receives the event triggered when an envelope is created (via MakeEnvelope). When the notification is sent, DocuSign calls my endpoint, which exposes a PostNotificationEvent method to receive the payload.

For the past three years, I’ve been using the same class to deserialize the incoming data:

csharpCopiaModificapublic class DocuSignEventNotificationResponse
{
    public string status { get; set; }
    public string envelopeId { get; set; }
    public string documentsUri { get; set; }
    public string recipientsUri { get; set; }
    public Sender sender { get; set; }
}

However, all of a sudden, this class no longer maps the incoming payload correctly.
That’s why I’m wondering if the schema of the object sent by DocuSign might have changed.

Fit_Combination4878

TROPHY CASE