Genesys Cloud - Developer Community!

 View Only

Sign Up

  • 1.  Is it possible to set participant attributes during blind/consult transfer via Interaction.updateState?

    Posted 5 days ago

    Hi,

     

    I am implementing a CRM integration using the Genesys Cloud Embeddable Framework (Web softphone).

     

    In framework.js, I have enabled customInteractionAttributes and allowed a custom attribute:

     

    customInteractionAttributes: [
      "PT_TransferContext"
    ]

     

    Using PureCloud.Interaction.updateState with action "blindTransfer" or "consultTransfer",
    the transfer itself works correctly.

     

    What I am trying to achieve is:
    - At transfer time, set a participant attribute (e.g. PT_TransferContext)
    - Have that value available on the receiving agent side via the screenPop event

     

    Observations so far:

     

    1. Interaction.updateState
       - blindTransfer / consultTransfer only support participantContext
         (transferTarget / transferTargetType)
       - There does not appear to be a way to attach participant attributes here

     

    2. PureCloud.addTransferContext
       - Seems to work only when the Transfer window is open
       - If the Transfer Workspace checkbox is not selected, attributes are not propagated
       - There does not appear to be a way to:
         - open the Transfer window programmatically
         - force-enable the Transfer Workspace checkbox

     

    3. In a UI-based test:
       - When the Transfer window is manually opened
       - and addTransferContext is called while it is open
       - attributes are propagated correctly and appear in screenPop
       - but without the UI, the same call has no effect

     

    Given this behavior, my question is:

     

    Is there any supported way to set participant attributes that appear in screenPop
    when executing blindTransfer / consultTransfer via Interaction.updateState,
    without relying on the Transfer UI?

     

    If not, is this behavior intentional by design?

     

    Any clarification on the recommended or intended approach would be appreciated.

     

    Thanks.

    #EmbeddableFramework

    ------------------------------
    Katsuya Watabe
    ------------------------------


  • 2.  RE: Is it possible to set participant attributes during blind/consult transfer via Interaction.updateState?
    Best Answer

    Posted 5 days ago
    Edited by Katsuya Watabe 5 days ago

    Hi Katsuya,

    I haven't implemented this exact scenario myself, but from what I found, it does not look like custom participant attributes can be added directly inside the Interaction.updateState transfer call.

    The likely approach would be:

    1. Update the participant data/attributes on the active interaction first via API
    2. Wait for that update to complete
    3. Then trigger the blindTransfer / consultTransfer

    This thread looks relevant for updating participant data via API:


    https://community.genesys.com/discussion/manually-add-participant-data-to-an-active-interaction-via-the-api

    Also worth noting that participant data updates may propagate asynchronously, so timing could matter before triggering the transfer:


    https://community.genesys.com/discussion/participant-data-updates-via-the-api-performance-guarantee

    Hopefully someone from the community or Genesys can add more or confirm the intended approach.



    ------------------------------
    Phaneendra
    Technical Solutions Consultant
    ------------------------------



  • 3.  RE: Is it possible to set participant attributes during blind/consult transfer via Interaction.updateState?

    Posted 5 days ago

    Hi Phaneendra,
    Thank you very much for your prompt response.
    The behavior you described matches the results we observed in our own testing.

     

    Ideally, we would have liked to automate the screen ID/context handoff by combining
    addTransferContext with blind/consult transfer, but if this is the intended behavior
    of the current design, we understand the limitation.

     

    Regarding the approach of updating participant attributes via the API prior to transfer,
    we are also aware that timing dependencies and potential race conditions could be a concern.
    We will internally evaluate whether to proceed with an API-based implementation
    or to adopt a more manual operational approach instead.

     

    Thank you again for sharing your insights and references.


    ------------------------------
    Katsuya Watabe
    ------------------------------



  • 4.  RE: Is it possible to set participant attributes during blind/consult transfer via Interaction.updateState?

    Posted 5 days ago

    Hi Katsuya,

    Thank you for the update, really appreciate you sharing your findings and approach.

    It would be great to hear which path you end up taking and how it works out.

    Thanks again 



    ------------------------------
    Phaneendra
    Technical Solutions Consultant
    ------------------------------



  • 5.  RE: Is it possible to set participant attributes during blind/consult transfer via Interaction.updateState?

    Posted 4 days ago

    +1 to Phaneendra for including all the required information.
    Just to rephrase for readers: 

    Attributes can only be reliably set after the transfer, once the target participant becomes part of the active interaction. For e.g. 
    during a blind /consult transfer, the consult leg doesn't expose a supported hook to update participant attributes before the transfer completes.
    So if attributes are required for downstream logic, the update needs to happen post‑transfer.

    Thanks


    ------------------------------
    Ashiesh Sharma
    GCX- GCP, ARC, SCR, QM
    Producer | Conductor | Composer
    BT plc
    ------------------------------



  • 6.  RE: Is it possible to set participant attributes during blind/consult transfer via Interaction.updateState?

    Posted 4 days ago

    Hi Ashiesh,

     

    Thank you very much for the clarification and for sharing the recommended approach.
    Your explanation regarding post‑transfer participant attribute updates makes sense,
    especially from a reliability and platform‑support perspective.

     

    In our case, however, the primary goal is slightly different.
    What we are aiming to achieve is passing contextual information (such as a screen ID)
    *at the time of the transfer*, so that the target agent can have the relevant screen
    opened or popped immediately when receiving the call.

     

    Because of this, updating participant attributes only after the transfer completes
    would not fully satisfy our use case, as the purpose is not to persist data post‑handoff,
    but to enable real‑time context sharing during the transfer itself.

     

    That said, we completely understand the platform constraints you described,
    and we appreciate you taking the time to clearly explain the supported model.

     

    Thank you again for the helpful insights.


    ------------------------------
    Katsuya Watabe
    ------------------------------



  • 7.  RE: Is it possible to set participant attributes during blind/consult transfer via Interaction.updateState?

    Posted 4 days ago
    Edited by Phaneendra Avatapalli 4 days ago

    Hi Katsuya,

    Just a thought - not sure if you've already considered this, but you could use interaction notes to pass something like the screen ID during the transfer.

    You can make notes about an interaction during the interaction or while in ACW.

    It wouldn't give you an automated screen pop, but for passing a simple value like an ID, it might work as a lightweight fallback.

    Resource - https://help.genesys.cloud/articles/enter-notes-for-an-interaction/

    Hope this helps.



    ------------------------------
    Phaneendra
    Technical Solutions Consultant
    ------------------------------



  • 8.  RE: Is it possible to set participant attributes during blind/consult transfer via Interaction.updateState?

    Posted 3 days ago

    Hi Phaneendra,

     

    Thank you for the suggestion and for sharing this idea.
    While it doesn't fully fit our current requirement for real‑time screen pop during the transfer,
    it's definitely useful to keep in mind as an option for other scenarios with different needs.

     

    We really appreciate you taking the time to share your thoughts - it adds to our toolbox
    for future designs.

     

    Thanks again.


    ------------------------------
    Katsuya Watabe
    ------------------------------