Virtual Agent, NLU Models: What are Best Practices for Scoping?

[Raj64]

Hello all,

We're still getting ready for our production release of Virtual Agent.

As I'm learning and developing topics, I've come across a scenario where a duplicated OOB topic (Troubleshoot Slow Computer) doesn't work because the scope of the original topic is "ITSM Virtual Agent Conversations" and the duplicated topic is global. When I change the scope of the topic from global to ITSM Virtual Agent Conversations, it works, but doesn't find its NLU (because the NLU scope is also global).

This brings me to several questions (best practices for topic scope):

1. Should I create all my topics and NLU models in the ITSM Virtual Agent Conversations scope?
2. Should I only create topics that require ITSM Virtual Agent Conversations scope within that scope and the rest global? This would require me to split my NLU models and possibly duplicating intents into two models, one for each scope.
3. Would update sets capture the scope of the topic? Or is there another way of deploying the topics if I choose option #1 above?

Thanks.

[Raj64]

Thank you for taking the time to respond Chris. I appreciate it!

[Patrick71]

The biggest headache I ran into with scoping in VA was queries in script being denied cross scope access.  When I built a topic in the Virtual Agent Service Portal Widgets scope with the following script, the log showed it breaking at query(). I still don't understand why, as the sys_cs_topic table allowed read from all application scopes.

When I duplicated the topic in the global scope, it worked perfectly fine.

(function execute() {
   
    var options = [];

    var grTopics = new GlideRecord('sys_cs_topic');
    //Active, visible, discoverable, and categorized as either ITSM IT Issues, ITSM Fulfiller, ITSM Actionable Notifications, or ITSM Self Service
    grTopics.addActiveQuery();
    grTopics.addEncodedQuery('design_categoryLIKE3efd22da0b203300a1b16c2367673a10^ORdesign_categoryLIKE5ca81c5a7331201083c1e0dbc4f6a7f8^ORdesign_categoryLIKEbfdd66da0b203300a1b16c2367673a1f^ORdesign_categoryLIKE140e2eda0b203300a1b16c2367673af4^visible=true^discoverable=true');
    grTopics.query();

    while(grTopics.next()){
        var topicName = grTopics.getValue('name');
        options.push({ 'value': topicName, 'label': topicName, 'render_style': 'data'});
    }

    
    return options;
})()

[Tricia Cornish]

Scope always gets me too. I'm commenting with my solution so that others can chime in on the correct/incorrect use of Application Cross-Scope Access. 

Are the topics you are querying in other scopes? have created records in Application Cross-Scope Access for the sys_cs_topic between my scopes as well as my custom scope and global scope. In my example, I have my custom IT topics in the ITSM VA conversations scope and had created a "shared topic" in my custom Employee Experience scope so have a record in my here to retrieve that. 

If you're querying ITSM IT, Fulfiller, etc, and those are in the ITSM Virtual Agent Conversations scope, you might try creating a record between your VA Service portals widget scope and ITSM VA scope for the table. 
Hope that helps! 

[davidpridemore1]

I had the same issue with a slightly different but similar use case. Had my virtual agent topic in a scoped app, and wanted to take an action on a global table. I created a vaUtils script include in the global scope, then created an execute API cross scope privilege from my source scope (virtual agent scoped app) to the target scope (global) and the target being my new vaUtils script include.

At that point you can just have your various scripted actions as object methods or attributes and they'll run correctly. Test with background scripts to make sure the scope rule is working properly, and make sure to call the global qualifier in your VA script block. I pass vaVars and vaInputs as vaUtils function parameters and then I can capture user input to do whatever I wanted on the target record.

This was after multiple hours of trying to configure the target tables to allow create/write access via table access rules and cross scripting rules from my custom scope to global. Also tried a caller access record but global isn't available as a target. This is the only way I've been able to get it to work.