When configuring SCIM with OKTA, the attribute under (primaryPhone) uses our AD (Telephone number)

Is there a way to change the input field to the "ext" field instead of "Work Phone"?

When configuring SCIM with OKTA, the attribute under (primaryPhone) uses our AD (Telephone number)

Is there a way to change the input field to the "ext" field instead of "Work Phone"?

The SCIM APIs that are being leveraged support the setting of the extension only within a particular phone number type by leaving the tel: portion of the e.164 formatted number blank, like  "tel: ; ext=xxxxx".  This is accounted for in a tool like Azure AD by using an expression to manipulate the string that is sent as part of the phone number update on a user (see: https://help.mypurecloud.com/articles/configure-azure-active-directory-for-genesys-cloud-scim-identity-management/#Extensions).  I'm not entirely sure how you'd achieve this within Okta, as their tooling for modifying strings within their user provisioning is more sparsely documented than Azure AD, but it would certainly be worth a quick question to Okta to determine how you might achieve this payload being sent to our API.

When configuring SCIM with OKTA, the attribute under (primaryPhone) uses our AD (Telephone number)

Is there a way to change the input field to the "ext" field instead of "Work Phone"?

The SCIM APIs that are being leveraged support the setting of the extension only within a particular phone number type by leaving the tel: portion of the e.164 formatted number blank, like  "tel: ; ext=xxxxx".  This is accounted for in a tool like Azure AD by using an expression to manipulate the string that is sent as part of the phone number update on a user (see: https://help.mypurecloud.com/articles/configure-azure-active-directory-for-genesys-cloud-scim-identity-management/#Extensions).  I'm not entirely sure how you'd achieve this within Okta, as their tooling for modifying strings within their user provisioning is more sparsely documented than Azure AD, but it would certainly be worth a quick question to Okta to determine how you might achieve this payload being sent to our API.

------------------------------
Richard Schott
Genesys - Employees

Original Message:
Sent: 09-28-2023 07:57
From: Francisco Duran
Subject: OKTA SCIM into field sync with Genesys Cloud

When configuring SCIM with OKTA, the attribute under (primaryPhone) uses our AD (Telephone number)

Is there a way to change the input field to the "ext" field instead of "Work Phone"?

#Implementation

------------------------------
Francisco Duran
Genesys - Employees
------------------------------

Hello,

For the ext field, do you happen to know the variable name and external name for the ext field box for "work"

------------------------------
Phi Nguyen
Shield Healthcare

Original Message:
Sent: 10-02-2023 09:02
From: Richard Schott
Subject: OKTA SCIM into field sync with Genesys Cloud

The SCIM APIs that are being leveraged support the setting of the extension only within a particular phone number type by leaving the tel: portion of the e.164 formatted number blank, like  "tel: ; ext=xxxxx".  This is accounted for in a tool like Azure AD by using an expression to manipulate the string that is sent as part of the phone number update on a user (see: https://help.mypurecloud.com/articles/configure-azure-active-directory-for-genesys-cloud-scim-identity-management/#Extensions).  I'm not entirely sure how you'd achieve this within Okta, as their tooling for modifying strings within their user provisioning is more sparsely documented than Azure AD, but it would certainly be worth a quick question to Okta to determine how you might achieve this payload being sent to our API.

------------------------------
Richard Schott
Genesys - Employees

Original Message:
Sent: 09-28-2023 07:57
From: Francisco Duran
Subject: OKTA SCIM into field sync with Genesys Cloud

When configuring SCIM with OKTA, the attribute under (primaryPhone) uses our AD (Telephone number)

Is there a way to change the input field to the "ext" field instead of "Work Phone"?

#Implementation

------------------------------
Francisco Duran
Genesys - Employees
------------------------------

What needs to be sent to us would be something like:

{
  "phoneNumbers": [
    {
      "type": "work",
      "value": "tel: ; ext=1234"
    }
  ]
}

to https://developer.genesys.cloud/useragentman/scim/scim-apis#put-api-v2-scim-users--userId-

What we have documented for Azure AD (https://help.mypurecloud.com/articles/configure-azure-active-directory-for-genesys-cloud-scim-identity-management/#Extensions) generates a payload that follows this pattern based, sending it to the configured phone number type

Hello,

For the ext field, do you happen to know the variable name and external name for the ext field box for "work"

------------------------------
Phi Nguyen
Shield Healthcare

Original Message:
Sent: 10-02-2023 09:02
From: Richard Schott
Subject: OKTA SCIM into field sync with Genesys Cloud

The SCIM APIs that are being leveraged support the setting of the extension only within a particular phone number type by leaving the tel: portion of the e.164 formatted number blank, like  "tel: ; ext=xxxxx".  This is accounted for in a tool like Azure AD by using an expression to manipulate the string that is sent as part of the phone number update on a user (see: https://help.mypurecloud.com/articles/configure-azure-active-directory-for-genesys-cloud-scim-identity-management/#Extensions).  I'm not entirely sure how you'd achieve this within Okta, as their tooling for modifying strings within their user provisioning is more sparsely documented than Azure AD, but it would certainly be worth a quick question to Okta to determine how you might achieve this payload being sent to our API.

------------------------------
Richard Schott
Genesys - Employees

Original Message:
Sent: 09-28-2023 07:57
From: Francisco Duran
Subject: OKTA SCIM into field sync with Genesys Cloud

When configuring SCIM with OKTA, the attribute under (primaryPhone) uses our AD (Telephone number)

Is there a way to change the input field to the "ext" field instead of "Work Phone"?

#Implementation

------------------------------
Francisco Duran
Genesys - Employees
------------------------------

Richard,

If you can create an additional "type" for just workext? to fill in that text box? That would work for me if possible.

What needs to be sent to us would be something like:

{
  "phoneNumbers": [
    {
      "type": "work",
      "value": "tel: ; ext=1234"
    }
  ]
}

to https://developer.genesys.cloud/useragentman/scim/scim-apis#put-api-v2-scim-users--userId-

What we have documented for Azure AD (https://help.mypurecloud.com/articles/configure-azure-active-directory-for-genesys-cloud-scim-identity-management/#Extensions) generates a payload that follows this pattern based, sending it to the configured phone number type

Hello,

For the ext field, do you happen to know the variable name and external name for the ext field box for "work"

------------------------------
Phi Nguyen
Shield Healthcare

Original Message:
Sent: 10-02-2023 09:02
From: Richard Schott
Subject: OKTA SCIM into field sync with Genesys Cloud

The SCIM APIs that are being leveraged support the setting of the extension only within a particular phone number type by leaving the tel: portion of the e.164 formatted number blank, like  "tel: ; ext=xxxxx".  This is accounted for in a tool like Azure AD by using an expression to manipulate the string that is sent as part of the phone number update on a user (see: https://help.mypurecloud.com/articles/configure-azure-active-directory-for-genesys-cloud-scim-identity-management/#Extensions).  I'm not entirely sure how you'd achieve this within Okta, as their tooling for modifying strings within their user provisioning is more sparsely documented than Azure AD, but it would certainly be worth a quick question to Okta to determine how you might achieve this payload being sent to our API.

------------------------------
Richard Schott
Genesys - Employees

Original Message:
Sent: 09-28-2023 07:57
From: Francisco Duran
Subject: OKTA SCIM into field sync with Genesys Cloud

When configuring SCIM with OKTA, the attribute under (primaryPhone) uses our AD (Telephone number)

Is there a way to change the input field to the "ext" field instead of "Work Phone"?

#Implementation

------------------------------
Francisco Duran
Genesys - Employees
------------------------------

The SCIM APIs that are being leveraged support the setting of the extension only within a particular phone number type by leaving the tel: portion of the e.164 formatted number blank, like  "tel: ; ext=xxxxx".  This is accounted for in a tool like Azure AD by using an expression to manipulate the string that is sent as part of the phone number update on a user (see: https://help.mypurecloud.com/articles/configure-azure-active-directory-for-genesys-cloud-scim-identity-management/#Extensions).  I'm not entirely sure how you'd achieve this within Okta, as their tooling for modifying strings within their user provisioning is more sparsely documented than Azure AD, but it would certainly be worth a quick question to Okta to determine how you might achieve this payload being sent to our API.

When configuring SCIM with OKTA, the attribute under (primaryPhone) uses our AD (Telephone number)

Is there a way to change the input field to the "ext" field instead of "Work Phone"?

Here what OKTA support say.

Hi Phi,

Thanks for getting back to me. I understand what their support is getting at here, however it is my understanding that the phone number in this case is a base attribute. While Okta can send multivalued attributes via a custom attribute we cannot stop the integration from attempting to send two values to the same attribute which would result in an error. From what I am seeing is that this is as we thought unsupported.

Thank you,

Alexander Jones
Technical Support Engineer
Okta Global Customer Care

The SCIM APIs that are being leveraged support the setting of the extension only within a particular phone number type by leaving the tel: portion of the e.164 formatted number blank, like  "tel: ; ext=xxxxx".  This is accounted for in a tool like Azure AD by using an expression to manipulate the string that is sent as part of the phone number update on a user (see: https://help.mypurecloud.com/articles/configure-azure-active-directory-for-genesys-cloud-scim-identity-management/#Extensions).  I'm not entirely sure how you'd achieve this within Okta, as their tooling for modifying strings within their user provisioning is more sparsely documented than Azure AD, but it would certainly be worth a quick question to Okta to determine how you might achieve this payload being sent to our API.

When configuring SCIM with OKTA, the attribute under (primaryPhone) uses our AD (Telephone number)

Is there a way to change the input field to the "ext" field instead of "Work Phone"?

I am so confused here.  Phone numbers have types.  Each Type can have a phone number, an extension, or both.  This is how the RFC is written.  They payloads I pasted above are what needs to get sent in order to populate an extension only (the first example) or a phone number plus the extension (second example).  In the event phone number and extension are stored on separate attributes in Okta, then they would need to either be concatenated together in order to create a payload like the second example (this is what is being covered in the Azure AD documentation I provided initially, discussing how the expression tooling works within Azure AD to create a concatenated payload to set both the phone number and extension in a single API request).

If Okta is unable to provide concatenation, then some decisions need to be made as to how these numbers are being used.  The phone number could be sent to one phone type, and the extension to another; or the extension only could be used (assuming the phone number is not particularly unique/important).  Regardless, it's important to note that this limitation falls on Okta's end, as Genesys Cloud is providing the APIs that conform with the SCIM RFC, and it is up to the provisioning engine within Okta to properly format the data it is sending to those APIs.  

Here what OKTA support say.

Hi Phi,

Thanks for getting back to me. I understand what their support is getting at here, however it is my understanding that the phone number in this case is a base attribute. While Okta can send multivalued attributes via a custom attribute we cannot stop the integration from attempting to send two values to the same attribute which would result in an error. From what I am seeing is that this is as we thought unsupported.

Thank you,

Alexander Jones
Technical Support Engineer
Okta Global Customer Care

The SCIM APIs that are being leveraged support the setting of the extension only within a particular phone number type by leaving the tel: portion of the e.164 formatted number blank, like  "tel: ; ext=xxxxx".  This is accounted for in a tool like Azure AD by using an expression to manipulate the string that is sent as part of the phone number update on a user (see: https://help.mypurecloud.com/articles/configure-azure-active-directory-for-genesys-cloud-scim-identity-management/#Extensions).  I'm not entirely sure how you'd achieve this within Okta, as their tooling for modifying strings within their user provisioning is more sparsely documented than Azure AD, but it would certainly be worth a quick question to Okta to determine how you might achieve this payload being sent to our API.

When configuring SCIM with OKTA, the attribute under (primaryPhone) uses our AD (Telephone number)

Is there a way to change the input field to the "ext" field instead of "Work Phone"?

Richard,

I have a case with genesys #000337239, are we able to setup a meeting with okta and yourself to find a solution?

Thanks,

I am so confused here.  Phone numbers have types.  Each Type can have a phone number, an extension, or both.  This is how the RFC is written.  They payloads I pasted above are what needs to get sent in order to populate an extension only (the first example) or a phone number plus the extension (second example).  In the event phone number and extension are stored on separate attributes in Okta, then they would need to either be concatenated together in order to create a payload like the second example (this is what is being covered in the Azure AD documentation I provided initially, discussing how the expression tooling works within Azure AD to create a concatenated payload to set both the phone number and extension in a single API request).

If Okta is unable to provide concatenation, then some decisions need to be made as to how these numbers are being used.  The phone number could be sent to one phone type, and the extension to another; or the extension only could be used (assuming the phone number is not particularly unique/important).  Regardless, it's important to note that this limitation falls on Okta's end, as Genesys Cloud is providing the APIs that conform with the SCIM RFC, and it is up to the provisioning engine within Okta to properly format the data it is sending to those APIs.