Skip a node if user comes from a specific topic

[Yasmin]

We are building a topic that will show a static choice control only IF the user is coming from a specific. So depending on the topic that ran prior to the present topic, then the static choice control would/would not show.

Anyone done something similar before?

[Chris D]

I've done this - maybe not the most elegant so by all means happy to hear other ideas.

To be specific, in my case, I have a custom Feedback Setup Topic (spawns 33% of the time by default) that calls the ootb Survey topic block and I didn't want users of certain topics - including folks who just completed the Survey - to have to do the survey at the end of their conversation, even if they met the random 33%.

I believe I implemented it before the "Conditionally use this node if..." feature was added, so I actually just put this script in a decision block, but now the best place to put the script would be in the node conditions. And note this seems to continue working properly in San Diego as it did on Quebec - and I think Orlando too - but of course it's no guarantee ServiceNow won't change the data structure and break this in the future.

Basically, I'm just querying the Conversation Task table to see if this user's current conversation included any of those topics. (Note: if you put this in a node condition, you'll want to flip the true/false at the end, i.e. return false if it matches your specific topic(s))

(function execute() {
    //skip the survey for users who used TOPIC A or B
    //or Survey (preventing a redundant survey)

    var gr = new GlideRecord('sys_cs_conversation_task');
    //look for all topics (conversation tasks) within this same conversation
    gr.addQuery('conversation', vaVars.global_vCurrentTopicId);
    //look specifically for TOPIC A
    var grOR = gr.addQuery('topic_type','044b7315dbbb081026a61fdc139619a3');
    //or Survey
    grOR.addOrCondition('topic_type','26baac293b77330074bc456993efc4dd');
    //or TOPIC B
    grOR.addOrCondition('topic_type','fe79ee8bdb9e601097190825ca96197d');
    gr.query();
    if (gr.next()){
        return true;
    }
    else {
        return false;
    }
})()

If that's too general for you - keep in mind a user COULD use multiple topics in one conversation - and you want to get more in depth, here's some additional logic I use in a topic block to lookup the "calling"/previous topic (Conversation Task). You can do a combination of the two scrips to achieve what you need more precisely. 

    //get the current Conversation sys_id to find the Conversation Task(s)
    var currentConversation = vaSystem.getConversationId();
    //get the current Conversation Task - which is this topic block, the latest Conversation Task
    var currentTask = new GlideRecord('sys_cs_conversation_task');
    currentTask.addQuery('conversation', currentConversation);
    currentTask.orderByDesc('sys_created_on');
    currentTask.query();
    currentTask.next();
    //get the previous Conversation Task - this will be the actual topic that called this topic block
    var previousTask = new GlideRecord('sys_cs_conversation_task');
    previousTask.get(currentTask.calling_task);

[Richard Kiss1]

Hi Yasmin,

An easy way to do this is to create a new LiveAgent variable (Conversational interfaces > Chat Setup Context tab) and select that variable in the Properties of Your specific topic and the receiving topic as well.

The live agent variables persisting through the whole conversation, so they are not reset when a topic ends or a new one starts.

You can set the value of this new variable to true for example before the end of the specific topic and check it at your receiving topic to see if the value is true or not separating your flow logic based on that.

Richard

[Chris D]

I like this. Seems much more elegant and less prone to future update breaking than my hacky solution 😄

I've never created custom LiveAgent (context) variables myself, but from my continued learning of their use cases, I'm convinced that they are poorly branded because they're not at all exclusive to Live Agent chat and are just as, if not more, useful in VA chats for passing data between topics.

Another very similar thing is (regular) context variables. I've used these before, but I've only ever set them via a URL parameter and I'm not sure if you can set them via a VA script. These are nice because you don't need to manually add them to each topic. The documentation makes it seem like you can't set them in a script (in fact there's a handful of ootb vaContext.[variable]'s), but  I've never tried. For reference from Virtual Agent scripts (servicenow.com):

Context variables contain information pertaining to the context of the user or instance. These variables can be used anywhere in the conversation using the vaContext object.

You can also create a context variable via system parameters in a URL. The following example link contains a parameter, sysparm_city=milan. In addition to opening a Virtual Agent conversation, using this link creates a variable called city with a value of milan. This variable can be accessed in a script using vaContext.city.

https://<instance>.service-now.com/$sn-va-web-client-app.do?sysparm_city=milan