Genesys Cloud - Main

Sign Up

  Thread closed by the administrator, not accepting new replies.

  • 1.  Unexpected behaviour in attributes from scripts

    Posted 09-05-2018 02:07
    No replies, thread closed.
    Hi all, 

    I am currently working on some changes to one of the pop scripts in our organisation.

    I have a scenario where a call needs to have a new skill applied to it and then moved back to a general queue, with a view of moving the caller to an agent appropriately skilled in their enquiry.

    To achieve this, my pop script has a dropdown where the current agent would select what the call itself is about, and this updates a variable, call it "ScriptSetRequiredSkill", this variable is stored with intention of GETting it in an in-queue flow, but when I get the variable, there is no data accessible (I assume because its "ScriptSetRequiredSkill" not "Flow.ScriptSetRequiredSkill")

    Looking at the conversation breakdown, I can see the attribute is stored - I cant pass it from the script as "Flow.ScriptSetRequiredSkill" as dots (".") are not permitted.

    Has anyone seen this behaviour?

    ------------------------------
    Thanks in advance

    Matt Johansson
    Deakin University
    ------------------------------


  • 2.  RE: Unexpected behaviour in attributes from scripts

    Posted 09-05-2018 10:45
    No replies, thread closed.
    In architect all variables have a scope.  Flow. means a variable is available throughout the entire flow.  Task. means the variable is available only in the current task.  Also the variable name doesn't have anything to do with looking up the participant value.  The Attribute Name value is what must match the participant value from the conversation; the Variable To Assign is just the name of the variable that will store the value so you can use it in the flow.  

    As for why your in-queue flow doesn't "see" the attribute on the conversation--that has to with how the script decides which participant to put the variable onto, and which participant(s) the flow checks.  If you look at the conversation, you will notice there are 2 participant with attributes.  The in-queue flow finds a participant with attributes which is the incoming caller and stops looking.  Unfortunately the script puts the data on a different participant, the agent who handled the call.  The workaround is to do a Set Participant Data action in the inbound call with the attribute name of ScriptSetRequiredSkill.  Set the Value to Assign to either a default value (if that makes sense), or a value that you will know to ignore b/c the agent didn't set it.  This will force the attribute to be assigned to the same participant that the in-queue flow will find.

    ------------------------------
    Melissa Bailey
    Genesys - Employees
    ------------------------------

    Original Message


Related Content