Skip to main content

    Filter by idea status

    Filter by product

    1294 Ideas

    yagarwal
    yagarwalEmployee

    Copilot Support for Classic Use Cases6. Delivered

    What is itBring all your Creator Studio use cases (from the Classic architecture) to the new Copilot architecture as plugins. Key DatesLimited Preview: March 2024 Preview: August 2024 Current StateQueries & Events in Copilot are already in Preview! Paths in Copilot is in Limited Preview. Please use the experimental feature tab to enroll in the feature! We have finished implementing core capabilities and we are working on some ML enhancements before launching the capability to Preview. Key improvementsCopilot’s generative framework brings intelligent reasoning to your Creator Studio use cases. This means many out-of-the-box benefits (such as implicit slot filling, easy context switching & more). Check out our documentation for examples & details. Core CapabilitiesWe have finished implementing the core capabilities.Capability Name Status Release Date Paths - APIs, KBs & Free-text Solutions ✅ Supported Feb 2024 Paths - Free-input & multiple choice slots ✅ Supported Feb 2024 Paths - Date slots ✅ Supported April 2024  Paths - Markup support (free-text responses) ✅ Supported May 2024 Paths - Form actions ✅ Supported May 2024 Queries - API responses ✅ Supported Jan 2024 Queries - URL follow up actions ✅ Supported April 2024 Events - Event notifications ✅ Supported Jan 2024 Events - Event-triggered Paths ✅ Supported April 2024 Launch rules ✅ Supported Jan 2024 API logs ✅ Supported May 2024  Plugin ReliabilityAll plugins (especially multi-turn ones) have challenges when working with LLMs. LLMs may not correctly interpret how a plugin is supposed to be used. We want to ensure CREST plugins behave at least as well on NGCP (if not better). We’re evaluating & improving LLM behavior across a variety of LLM parameters to ensure this:Plugin selection: Does the plugin trigger when expected? Plugin re-selection: If a user replies to a plugin, does the Copilot stay focused? Slot filling: Are inputs extracted correctly? Question generation: When inputs are needed, is the Copilot clear (with help text as needed)? Inference confirmations: When inputs are assumed, is the user made aware? Action confirmations: Is the confirmation message clear before actions are executed? Response generation: Is the summary after actions are executed clear? Once we can guarantee a sufficient quality for LLM behavior with plugins, we will release the capability by default (as Preview). Related Roadmap CapabilitiesTo make it possible to control your plugins more reliably, we are introducing new developer controls. You can see those feature requests below. FAQQ. So when should I start rolling out Creator Studio in Copilot?A. You should start today (if you haven’t already)! We’ll continue to improve our LLM performance & build the above improvements over the next few months. Remember to enable the experimental feature flag for Paths in Copilot when you’re ready! Our team is excited to bring your Creator Studio plugins to Copilot. Please let us know what you think.

    Ajay ChikaneNew Participant

    Enhancements Needed for Knowledge Studio Integration and User Experience4. Future Consideration

    No rich text editor currently available to edit suggested articles => poor user experience for KB author No current integration with ServiceNow knowledge module for article editing => poor user experience for the KB author; extra time spent having to login and copy-paste suggested KB draft into SHARP No current integration with “Writing AI ready” Knowledge templates indicated by Moveworks and currently used to write articles that can be ingested by Ada => could result in publication of new articles that are not ingested “KB Updates” view should highlight (e.g. color coding) differences between existing KB and suggested KB by knowledge studio when these are opened side-by-side in 2 column view => to make clear for knowledge author what are the KB modifications suggested “Sources” indicated for KB update suggestion are not really individual sources, but different lines of text within a single INC with ingested Work Notes => this is misleading - knowledge author will interpret that an update suggestion comes from multiple tickets with related Work Notes. This skews perception of credibility of an update. Should be fixed so that 1 “source” stands for 1 ticket containing relevant hints for the respective KB update/creation suggestion. Knowledge Studio currently favors tickets with largest amount of Work Notes as a KB suggestion => for more accurate suggestions and information, the model should also consider ticket age (favor newer tickets over older ones), whether any major incident / problem ticket / P1-P2 ticket exists for the topic (might contain final resolution for a known major issue) … “KB Updates” currently only offers generic guidance on which KBs to update. For example, for a PKI Card KB Update suggestion, it displays a large number of existing KB articles without detailing which specific articles should the update be added in => model should be improved as to be more specific Information on knowledge gap areas per Coverage and Effectiveness used to be able in "Answers Insights" dashboard, now this has been significantly trimmed down within BPI. Can this type of dashboard or some metrics/info within be added to Knowledge Studio? Roles/Access management – need to clarify how this will align with our ServiceNow knowledge management roles => Granting Knowledge Studio access to every ServiceNow user with ITIL access is not something we want – some articles are restricted from view based on role. Also, before users are able to publish / edit articles, we require them to take specific trainings on the knowledge lifecycle and the KB editor tool. Additionally, we’d want them all to be trained in Knowledge Studio. 

    denis.barrosNew Participant

    Servicenow standard approvals notification with a clear reason for the approval4. Future Consideration

    Hey team, Would like to improve the servicenow standard approval request notification being sent to users:Currently the notification comes without a way to tell the users what the approvals are for, it simply shows the Request ticket where the approval is necessary. In instances where a request would need multiple approvals the user will never know at what stage is the approval being asked for.Firstly, the notification shows the “requested by” at the top of the notification, which is pointless because the user who opened the request is always the bot so it will never be different, unless the users fill the request outside the bot then it would show who opened it. This would be better served by using the requested for value instead. In instances where multiple approvals are needed on a single request, we want to let the user know what the approval is about without changing the Request record, this could be done by utilizing the sysapproval_approver short description of the approval record, which would describe what the approval is about for each approval request We need to be able to let users know not only from which request the approval is necessary for, but also letting them know what the approval is about. In approval record in Servicenow, theres short description which could be used for this (sysapproval_approver table)