Skip to main content

    Filter by idea status

    Filter by product

    1171 Ideas

    Slot Resolver strategy inference suggestions5. Not Enough Info to Make Decision

    Problems:We do not have much influence over how to get slots to infer (descriptions and the 3 inference options are nice, but are not sufficient in many use cases) Slot Resolver Strategies are very poor with inference when the options to choose are objects with multiple attributes. I can make it work by just outputting the name of the value (list of strings instead of list of objects), but I also have description values for each option object that I want to be considered to assist in choosing the correct option. This approach also means the api calls are made twice for resolver strategies: once in the resolver strategy to get the string list and then again to get the object in the conversational process which is needed for further actions. If a slot is inferred incorrectly, the user can ask for a change, but it doesn’t handle that change very reliably, if at all. Asking for all options of a slot does not always work and if it does, it usually is cut off after around 20.Current Workaround:Use a generate_structured_value_action to take in a description slot (and possibly others like the user) and do the selection This enables me to pass it multiple attributes to use for selection and build out a detailed prompt on how to choose the proper values. I have it also return a confidence score so if it isn’t confident in the choice, I can exit the plugin with information to provide more detail One negative here is that it then lacks the full context of the conversation. I can try and grab the context with a slot, but that does not always work reliably. Use plugin, conversational process, and slot descriptions to try and influence behavior as much as possible for choosing options and displaying options properly, but this does not always work reliably.While this is working well, I want slots themselves to be able to handle this sort of behavior instead of building around the problems.Proposed solutions:For a slot, give us a text box to define the system_prompt and user_input just like the generate_structured_value_action. This should work seamlessly with resolver strategies. The system prompt can define the logic on how to use inputs to choose the proper slot value and when it is necessary to ask the user for an exact value. For slots that are not set to always infer, always output a human readable version of the value selected on the action when it is selected. At any time afterwards, the user may request to change the value. If they do so, the conversational process goes back to the action where the slot is set as required and moves forward from there. Slots set as required in following steps should be reconsidered in this case. If a user asks to see all options of a slot that has a resolver strategy, all options are presented to the user and they are not cut off after ~20. The max I have currently is around 130 options for 1 slot. Most are under 20, but I do have multiple over this. Give the context as another system provided variable that can be leveraged in a conversational process like data and meta_info

    ffranzwaNew Participant

    Presentation options for user feedback in Agent Studio4. Future Consideration

    Our use case is similar to a CSAT Survey. In Classic Paths, we presented a series of static questions to the user, and they clicked on the appropriate button (Very Satisfied = 5 through Very Dissatisfied=1).We need additional features in order to replicate this functionality in Agent Studio:- “Human in the Loop” Action for Conversational Processes. This Action would always pause the conversational process to solicit an interaction with the user.- More control over how options are presented to the user- Show buttons to user for optionsOur Conversational Process has 7 “input” slots to capture the user feedback that is gathered over the course of the conversation. Each slot is set to “Always prompt user” with the desired question in the slot description and a resolver strategy with the possible responses. The bot still infers the user input since many of the slots have identical text in the resolver strategy. An explicit Action to ask for user input as part of the Conversational Process would be welcomed.We show ‘Very Satisfied’ to the user as the first option. The bot always picks this as ‘Option 1’ and allows users to select this option by pressing 1. Very Satisfied is a 5 and our users are familiar with that value due to how ServiceNow records this information. Asking users to select 1 for Very Satisfied is confusing and I do not see a way of preventing this from being shown to the users. We would like to have control over the presentation for soliciting user input. Along these lines, support for buttons and button labels with emojis would be welcomed.