Hi Jessica,
Thank you for evaluating API-driven inbound provisioning and sharing your questions.
Regarding this:
I'm looking to preserve the user's current Mail nickname in Microsoft if the user exists, and create a new Mail nickname if the user doesn't exist in Microsoft.
Based on the matching identifier configured, the provisioning service automatically determines whether to create or update a new user. If a user already has a mailNickname value and it is same as what you're sending with the API, then the provisioning service will not perform any change. Only if the values differ, then the provisioning service will update the value.
If you want to only set mailNickname when creating a user, then use the attribute mapping option "Apply this mapping -> Only during object creation."
Regarding the question:
Is there a way to pull the Mail nickname from the target system(Microsoft) if a matching user is found?
I'm assuming you're using the default mapping to perform the match with "externalId <-> employeeId" attribute pair. In this scenario, as mentioned above the provisioning service takes care of the comparison logic between other attributes in the mapping to determine what to update. So typically, you don't need to handle this in your implementation.
If instead of using "externalId <-> employeedId" as the matching pair, you want to use "externalId <-> mailNickname" as the matching pair, you can do that by updating the attribute mapping. Select the option "Match objects using this attribute" to "Yes". Accept the default matching precedence. Remove the matching setting for the "employeeId" attribute and save the configuration .
Regarding the question:
I've attempted to leverage Referenced Object Attributes but have been unable to get it to function properly. If Referenced Object Attribute is the solution, do you need an API expression as well?
Use Referenced object only to resolve reference attributes like manager. We recommend not tweaking these default settings for reference attributes.
Regarding the question:
how does the JSON need to be constructed in order for the application to process correctly?
The JSON must be constructed as a SCIM bulk request payload that uses the SCIM Core User and SCIM Enterprise User extension.
For examples refer to the API docs here: https://learn.microsoft.com/en-us/graph/api/synchronization-synchronizationjob-post-bulkupload?view=graph-rest-beta&tabs=http#example-1-bulk-upload-using-scim-core-user-and-enterprise-user-schema
In the provisioning app's attribute mapping, map the SCIM attributes to the Azure AD / on-prem AD attributes. If you want to send custom attributes (that are not part of the SCIM schema), then refer to the article: https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/inbound-provisioning-api-custom-attributes.
To learn more, refer to the learning path we suggest here for using this integration approach: https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/inbound-provisioning-api-concepts#recommended-learning-path.
Thanks,
Chetan