Genesys Cloud - Main

 View Only

Discussion Thread View
Expand all | Collapse all

OKTA SCIM into field sync with Genesys Cloud

  • 1.  OKTA SCIM into field sync with Genesys Cloud

    GENESYS
    Posted 09-28-2023 07:57

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

    image


    #Implementation

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


  • 2.  RE: OKTA SCIM into field sync with Genesys Cloud

    Posted 10-01-2023 13:24

    If your telephone numbers in AD are extensions, you can use Other Phone to sync the 4-6 digit extension as the phone number in Genesys.  This is the only field that can support non-e.164 numbers.  



    ------------------------------
    Robert Wakefield-Carl
    ttec Digital
    Sr. Director - Innovation Architects
    Robert.WC@ttecdigital.com
    https://www.ttecDigital.com
    https://RobertWC.Blogspot.com
    ------------------------------



  • 3.  RE: OKTA SCIM into field sync with Genesys Cloud

    GENESYS
    Posted 10-02-2023 09:03

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



  • 4.  RE: OKTA SCIM into field sync with Genesys Cloud

    Posted 10-02-2023 13:30

    Richard,

    I try that formatted, but it didn't work. I have a meeting with Okta later today regarding the issue have.

    Thanks,



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



  • 5.  RE: OKTA SCIM into field sync with Genesys Cloud

    Posted 10-02-2023 13:47
    Edited by Phi Nguyen 10-02-2023 13:57

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



  • 6.  RE: OKTA SCIM into field sync with Genesys Cloud

    GENESYS
    Posted 10-02-2023 14:56

    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



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



  • 7.  RE: OKTA SCIM into field sync with Genesys Cloud

    Posted 10-03-2023 10:33

    Richard,

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



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



  • 8.  RE: OKTA SCIM into field sync with Genesys Cloud

    GENESYS
    Posted 10-03-2023 10:43

    no, that's not how it works.  the ext is what indicates that the information goes into the extension field; the type is what indicates what type of phone number you're changing.  The above could be sent as:

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

    This would populate the phone number field in the work phone type to +13175551234 and the extension to 1234.  

    All of this is covered in great detail within the SCIM RFC.  In this case, Okta should be very familiar with this RFC, and would be in the best position to provide guidance on how to configuring their synchronization engine to send payloads that conform to the spec.



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



  • 9.  RE: OKTA SCIM into field sync with Genesys Cloud

    Posted 10-04-2023 09:25

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



  • 10.  RE: OKTA SCIM into field sync with Genesys Cloud

    GENESYS
    Posted 10-04-2023 10:16

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



  • 11.  RE: OKTA SCIM into field sync with Genesys Cloud

    Posted 10-04-2023 10:32

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



  • 12.  RE: OKTA SCIM into field sync with Genesys Cloud

    GENESYS
    Posted 10-04-2023 11:05

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



  • 13.  RE: OKTA SCIM into field sync with Genesys Cloud

    GENESYS
    Posted 10-04-2023 11:14

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



  • 14.  RE: OKTA SCIM into field sync with Genesys Cloud

    Posted 10-04-2023 16:58

    Hi Phi,

    Thanks for joining me earlier.

    As a quick recap we tried two methods, one was to fill the existing attribute with the provided example value however this lead to the entire string being sent to the phone number field leaving the EXT field Blank. We then constructed another attribute that should in theory match the example payload given by the SP support and were met with the same result.

    From here I believe what we will need to do is go through the process of provisioning a test user via postman, that way we can make sure the payload matches the given example perfectly. If possible would you be able to ask the SP support if they can view the payload being sent by Okta in this case? We will need to see if the attribute being passed is correctly reflecting the example payload given. 

    At this point I think our best course of action is to use postman, in this case hopefully SP support could walk you through provisioning a user via postman. I took a look at the Genesys Docs and can see that there is no defined value for the EXT box which would lead me to believe that there is special behavior being used in the connector that fills this value based on how the payload is populated, but we will need to confirm this. I spoke with some colleagues on my end regarding this and the consensus is that if this needs to be changed for the application it will need to be done through our ideas portal which unfortunately will not be a guarantee here.



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



  • 15.  RE: OKTA SCIM into field sync with Genesys Cloud

    Posted 10-10-2023 13:02

    Richard,

    Not sure if you saw my last response from OKTA.

    Thanks,



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



  • 16.  RE: OKTA SCIM into field sync with Genesys Cloud

    GENESYS
    Posted 10-10-2023 16:19
    Edited by Richard Schott 10-10-2023 16:19

    I did see it, and it basically did nothing to change what I wrote above.  My last post addresses basically everything you need to know about this issue, and needs to be communicated to Okta so they can guide you on how best to configure their system to produce the appropriate HTTP request payloads.  My response also echos what Robert told you, using "other" as a workaround, should Okta be unable to setup their system to produce the payloads specified in the RFC.  



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