Skip to main content

    Filter by idea status

    Filter by product

    1293 Ideas

    LAWRM064New Participant

    Expired Link Handling for Employee Communications1. New

    Problem StatementEmployee Communications campaign links (both in-text URLs and button links) currently expire after 14 days. When employees attempt to access an expired link, the experience is unclear and can lead to confusion, failed journeys, support requests, and reduced engagement with important communications.Proposed SolutionIntroduce a configurable expired-link experience that detects when a campaign link has expired and presents users with a clear, user-friendly message instead of a generic error or failed landing page.Key FeaturesCustomizable expired-link messaging Clear explanation that the communication link has expired Option to redirect users to: The latest version of the communication A help/support resource Admin-configurable expiration messaging and destination URLs Reporting on expired-link clicks to identify engagement after expirationBusiness ValueImproves employee experience and reduces confusion Decreases support tickets related to inaccessible communication links Preserves engagement with important communications after campaign expiration Provides administrators with greater flexibility and visibility into post-campaign activityUse Case An employee clicks a campaign link more than 14 days after receiving a communication. Instead of encountering a broken or inaccessible experience, they receive a friendly message explaining that the link has expired and are guided to the most current content or support resource.Priority Rationale Organizations using Employee Communications rely on campaign links to distribute important information. As adoption scales, a more graceful and intuitive expired-link experience becomes increasingly important to maintain trust, usability, and communication effectiveness.

    RyanPasca
    RyanPascaNew Participant

    Threshold of acceptability for enterprise search and knowledge articles1. New

    Goal: reduce frequency of bot responses that weakly match user intent. Reduce frequency of out-of-context bot responses.Product Idea: Would it be possible to add a feature allowing organizations using Moveworks to configure (perhaps within Moveworks Setup?) a threshold of acceptability for enterprise search?For example, a minimum matching score rating for knowledge matches to allow them to be surfaced. If there are no knowledge matches that meet the minimum matching score, then the bot would let the user know and offer to file a ticket or initiate live chat / agent handoff.I read about Moveworks Search “Ranking” at the link below, and understand Moveworks has specific ranking methodology to determine the priority order of which content to display.https://www.moveworks.com/us/en/resources/blog/enterprise-live-search-how-we-built-itHowever, this product idea addresses the scenario where Moveworks has nothing in its repository that meets the threshold and lets the user know, instead of citing a non-relevant or tangential topic. Instead, we would prefer the bot to reply with a statement along the lines of “I couldn't find a precise match for that. Would you like me to file a ticket for you?”We also envision this could workout when a plug-in triggers: It would be nice to have a threshold so that any enterprise search that comes up after a plug-in trigger, will have a very high likelihood of matching the plug-in content. So for example, when entering time, it would be best to only have articles that pertain to entering Time and not one for Expense (which it would most likely do in organizations where the two topics are so intertwined, and vocabulary across similar topic areas overlaps significantly.)I realize that if this feature existed, and an organization were to set the threshold too high, users could complain that the bot not knowing things. However if set too low, knowledge articles served would remain noisy, which can sometimes be the case currently.Here are a few Observations from Recent Chat Experience, testing interacting with the bot and asking it unique / obscure questions:The bot will occasionally ask the user to clarify if the question is unclear. It will say things like “It sounds like you may mean one of two things…”, without serving non-relevant articles. However, I did also find that the bot will tell the user when it cannot find a source that answers a highly-specific question, but it still will reply with links to articles that do not address the user’s direct intent. (happy to try to provide further examples if helpful)

    9002467New Participant

    Moveworks Displays "Reopen Issue" Option for RITMs That Cannot Be Reopened1. New

    Description:Artey currently presents colleagues with an option to reopen a previously submitted ServiceNow Requested Item (RITM) during conversational interactions. However, the underlying integration does not support reopening requested items, resulting in a poor user experience where users are offered an action that ultimately cannot be completed. As a result, colleagues may attempt to reopen requests through Artey only to encounter an error or unsuccessful outcome, creating confusion and reducing confidence in the assistant. Requested Enhancement:Update the Moveworks ServiceNow request management experience to validate whether a request type supports reopening before presenting the option to the user. If reopening is not supported for a given record type (such as RITMs), Moveworks should:Suppress the "Reopen Issue" action entirely for Requested Items, or Display a clear message indicating that reopening is not supported and provide alternative guidance, such as submitting a new request or contacting the appropriate support team.Business Impact:Eliminates misleading action prompts within Artey. Reduces colleague confusion and failed interactions. Improves trust in the assistant by only presenting supported actions. Decreases unnecessary support inquiries related to request reopening failures.Current Behavior:Artey offers users the ability to reopen a requested item (RITM), even though the action is not supported by the underlying process. Expected Behavior:Artey should only present a "Reopen Issue" option when the associated record type and workflow support reopening. Unsupported request types should not display the option. Acceptance Criteria:Moveworks validates reopen capabilities before displaying the action to users. RITMs that cannot be reopened do not display a "Reopen Request" option. Users receive clear guidance when reopening is unavailable. No failed reopen attempts occur for unsupported request types due to a presented Moveworks action.

    afleury
    afleuryInspiring

    Auto-map input arguments from HTTP Actions into Compound Actions and Conversation Processes1. New

    OverviewIt would be helpful if Agent Studio could automatically import or sync input arguments from an HTTP Action into the related Compound Action and Conversation Process.Today, inputs defined in an HTTP Action often need to be manually recreated or mapped again in the Compound Action, and then mapped again in the Conversation Process. While manageable for smaller actions, this becomes increasingly time-consuming and error-prone as actions grow in complexity.ExampleA ServiceNow Change Request action might require fields such as:short_description description start_date end_date risk_impact_analysisThese inputs are already defined within the HTTP Action, yet they must still be manually carried through multiple layers before the action can be used conversationally.This results in the same schema effectively being maintained three times: HTTP Action↓Compound Action↓Conversation ProcessSuggested ImprovementIntroduce an option such as:Import input arguments from HTTP Action Auto-map inputs Sync action schemaWhen enabled, Agent Studio would automatically propagate input definitions through the action chain while preserving:Field names Data types Descriptions Required/optional settings Default values Validation rulesBuilders could still override mappings manually if needed.BenefitsReduce repetitive configurationBuilders should not need to recreate the same inputs multiple times across different layers of the platform.Reduce mapping errorsThe more times a field is manually mapped, the greater the chance of:Missing fields Incorrect parameter mappings Out-of-sync schemas Placeholder values being accidentally passed throughFaster development and testingLess time spent maintaining mappings means more time spent:Building business logic Refining user experiences Testing new ideas Delivering value to end usersEasier maintenanceWhen an HTTP Action schema changes, updates could automatically flow through the action chain instead of requiring manual updates in multiple places.Why This MattersThis may be partially addressed by future capabilities such as Tool Architect, but there is still significant manual configuration required today when building actions.The biggest impact is not the time spent clicking through mapping screens. It's the interruption to the development flow.When experimenting with ideas, repeatedly recreating or remapping inputs across HTTP Actions, Compound Actions and Conversation Processes creates friction and slows iteration.For builders who enjoy exploring new use cases, prototyping solutions, or developing outside normal work hours, this repetitive setup work often becomes the limiting factor. Time that could be spent improving the experience, testing new patterns, or creating innovative solutions is instead spent maintaining mappings.Reducing this overhead would make Agent Studio more enjoyable to build in, encourage experimentation, and allow builders to focus on solving business problems rather than managing plumbing.Guiding PrincipleMap once, consume everywhere.Define an input once and have it available throughout the action chain, rather than maintaining the same schema across multiple layers.

    vinitbKnown Participant

    Simplify User Consent Authentication Flow1. New

    SummaryUsers are failing to complete the connector authentication flow because the current consent message is unclear and the button is easy to miss without a call-to-action .ProblemWhen a connector requires user consent, Moveworks displays a message that leads with what it can't do (e.g., "I can't do XYZ..."). User feedback shows that most people stop reading at that point and never see the button prompt — causing them to abandon the flow entirely.Two specific issues:Message framing — Opening with a negative statement causes users to disengage before reaching the action they need to take. Button label lacks a call to action — The button is labeled with the connector name only (e.g., "SYSTEM"), which doesn't signal to the user that they need to click it.Current Experience We also attempted a workaround by renaming the connector to "Connect With SYSTEM" to make the button more descriptive. However, this causes Moveworks to use the same name in the preceding sentence, resulting in grammatically incorrect messaging: "Connect with SYSTEM isn't connected." Attempted Workaround  Requested SolutionsOption 1 — Simplified Consent Message (Preferred)Replace the current message with a clear, action-oriented prompt: Please grant access to [Connector Name] by clicking the button below.[BUTTON] This approach is direct, positive in framing, and immediately tells the user what to do. Option 2 — Independent Control Over Button Label and Message TextAllow admins to configure the button label and the accompanying message text independently, so the button can have a meaningful call to action (e.g., "Grant Access") without affecting the connector name displayed in other parts of the message. ImpactThis change would directly reduce authentication drop-off. It improves the experience for all users who interact with connectors requiring consent.

    RanjiniNew Participant

    Title: Routing multiple HTTP error status codes without deep try_catch nesting1. New

     Hi everyone,This is a continuation of my previous post: Extracting dynamic JSON error messages from 4xx/5xx responses in a try_catch block.Because the JSON payload is dropped when an HTTP action hits a 4xx or 5xx status code, we are discussing a workaround with our API team: having them provide highly specific, unique HTTP status codes for every single type of business error (e.g., 422 = “Error Message 1”, 423 = “Error Message 2”, 424 = “Error Message 3”). This would theoretically allow us to hardcode specific, static fallback messages for each error scenario.The Challenge:Agent Studio only allows one catch block per try. If the API returns 10 different status codes and we want to show 10 different static messages, we can't simply use a switch expression inside a single catch block because the HTTP status code of the failed action isn't exposed as a variable in the Data Bank.Because of this, we are forced to write deeply nested try_catch blocks using the on_status_code filter to route each specific error. If we have 10 different error codes, this results in massive, hard-to-maintain YAML nesting.My Question:Is there a cleaner design pattern or workaround to route multiple status codes to different static messages without this deep nesting? How are others handling granular, status-code-based error routing in Compound Actions?