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.  

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 think that case number is missing a digit.  I'll be happy to take a look at it once I get the right number.

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.  

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 found the case, and if needed we can setup a quick meeting, but the answers to your question are in this thread.  In order to set the extension value of a phone type the payload Okta sends needs to be:

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

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

How Okta configures that is up to them.  If you are also using the phone number on the same type, then you need to concatenate extension and phone number (assuming they're in different fields) into one attribute mapping to send a payload like:
{
  "phoneNumbers": [
    {
      "type": "work",
      "value": "tel:+13175551234 ; ext=1234"
    }
  ]
}
Again, how this happens is up to Okta.  

Finally, if none of these options are possible because of limitations with Okta's provisioning system, your options are to either send the extension to the phone type of other (which is not e164 format validated) as Robert suggested, or consider performing your directory sync from AD (as you had indicated this is where the phone number field is coming from within Okta).  

I think that case number is missing a digit.  I'll be happy to take a look at it once I get the right number.

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.  

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 found the case, and if needed we can setup a quick meeting, but the answers to your question are in this thread.  In order to set the extension value of a phone type the payload Okta sends needs to be:

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

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

How Okta configures that is up to them.  If you are also using the phone number on the same type, then you need to concatenate extension and phone number (assuming they're in different fields) into one attribute mapping to send a payload like:
{
  "phoneNumbers": [
    {
      "type": "work",
      "value": "tel:+13175551234 ; ext=1234"
    }
  ]
}
Again, how this happens is up to Okta.  

Finally, if none of these options are possible because of limitations with Okta's provisioning system, your options are to either send the extension to the phone type of other (which is not e164 format validated) as Robert suggested, or consider performing your directory sync from AD (as you had indicated this is where the phone number field is coming from within Okta).  

I think that case number is missing a digit.  I'll be happy to take a look at it once I get the right number.

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.  

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,

Not sure if you saw my last response from OKTA.

Thanks,

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

Original Message:
Sent: 10-04-2023 11:14
From: Richard Schott
Subject: OKTA SCIM into field sync with Genesys Cloud

I found the case, and if needed we can setup a quick meeting, but the answers to your question are in this thread.  In order to set the extension value of a phone type the payload Okta sends needs to be:

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

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

How Okta configures that is up to them.  If you are also using the phone number on the same type, then you need to concatenate extension and phone number (assuming they're in different fields) into one attribute mapping to send a payload like:
{
  "phoneNumbers": [
    {
      "type": "work",
      "value": "tel:+13175551234 ; ext=1234"
    }
  ]
}
Again, how this happens is up to Okta.  

Finally, if none of these options are possible because of limitations with Okta's provisioning system, your options are to either send the extension to the phone type of other (which is not e164 format validated) as Robert suggested, or consider performing your directory sync from AD (as you had indicated this is where the phone number field is coming from within Okta).  

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

Original Message:
Sent: 10-04-2023 11:05
From: Richard Schott
Subject: OKTA SCIM into field sync with Genesys Cloud

I think that case number is missing a digit.  I'll be happy to take a look at it once I get the right number.

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

Original Message:
Sent: 10-04-2023 10:31
From: Phi Nguyen
Subject: OKTA SCIM into field sync with Genesys Cloud

Richard,

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

Thanks,

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

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

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.  

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

Original Message:
Sent: 10-04-2023 09:25
From: Phi Nguyen
Subject: OKTA SCIM into field sync with Genesys Cloud

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

------------------------------
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
------------------------------