
DanielC.72545 (Customer) asked a question.
Problem:
I have configured a SCIM application which is mostly working. However, OKTA sends duplicate entries for primary email and primary phone, both of type "work", sometimes with no value.
Use Case:
- All users will have a single "Work" email marked as primary
- Users will either have a single "Work" phone number marked as primary, or none at all as it's an optional field
Expectation:
- The PUT (update) SCIM calls should only contain a single element in the array or none at all
Flow:
- User is created in OKTA with the following attributes: userName, given/family name, and primary work email
- The user is assigned to the SCIM application
- OKTA calls my SCIM service which provisions the user
- A primary phone number is added to the user's profile in OKTA, triggering an update (PUT)
- The PUT request has multiple work emails in the emails array and 2 elements in the phoneNumbers array, one of which only has a type but no value. If I had specified the phoneNumber during creation, both phoneNumbers elements would have a value
Mappings:
The below mappings are all default and have not been modified
OKTA POST Request (works as expected, the phone number has not been assigned )
OKTA PUT
- Email has not been updated, but the emails array has 2 elements
- A single phone number was added to trigger the update. There are two elements in the phoneNumbers array, one with only a type and no value. I assume that's because no phone number was provided during creation.
Any idea why multiple work emails and phoneNumbers are being sent in the SCIM request?
Is this a bug, mapping issue, or something else entirely?

Hello Daniel,
Thanks for bringing this to our attention. Based on the conditions of the issue and the complexity of the scenario, is not something easy to reproduce in a lab environment and give you a clear answer based on that (at least not without having all the details of the config on your Org). My suggestion would be to open a ticket directly with Okta Support to address this.
Regards
JD Chacon