Build better products with our product team.
The thumbs up/down buttons are way smaller than the voting options in classic. Especially when dealing with users who have special needs it needs to be more accessible. Even regular users may not bother with giving feedback when it takes concentration to hit the button with the mouse. They should be a bit bigger than they are now.
Copilot understand when APIs are returning no records & handle the dialog appropriately. For Additional information - Please use -
Description:Adding the live chat interaction number (IMSxxxxx) and request ID to the analytics logs provided via Moveworks Data API for Smart Hand-off records is suggested.Business Need:These details are essential for accurately tracking live chat sessions, understanding user sentiment, and identifying areas for improvement. They enable more effective analysis of negative feedback and support the creation of reliable internal dashboards for performance monitoring.
It would be great if the Analytics provided in the Moveworks Portal could be integrated as a source with our Bot, allowing Admins and Analytics Users of Moveworks to query the Bot with questions vs. manually navigating to the portal and clicking through tabs and options. Example: Hey Bot, what has been the trend of active users over the last three months? Hey Bot, what are the top three feedback trends raised by users? This could even be extended to Roles and Permissions (does John Smith have access to analytics?) and Employee Experience Insights.
Requesting a new feature that would allow us to track the performance of the Interception skill ran on General Request, Work Request, and Incident tickets. Currently, we can obtain raw data from our Customer Success Team upon request. However, we all agree that this method is not sustainable in the long term as it is time-consuming for all parties involved.We believe it would be beneficial to have a feature that allows us to measure and track this skill. This would provide insights into the effectiveness of the Interception skill and aid in enhancing user interaction. Furthermore, it would help us understand whether our bot is providing the correct information/form or if users are disregarding our bot. This information would be invaluable in shaping our education strategy.Therefore, we kindly request that this metric be incorporated into the standard analytics dashboard for easy tracking. We believe this addition would greatly enhance our ability to monitor and improve the performance of our bot in the Interception Skill.
We noticed that Webhooks notifications do not have the option for users to react to them. This stops us from collecting feedback from users easily on their functionality.Would it be possible to have the option to have feedback 👍/👎 added to Webhook plugins as well? Maybe as a selectable option on the launch configuration page of the plugin.I’m working around the issue by adding a feedback form on our notification. Thanks in advance for reviewing this idea 😊
Allow users to toggle Dark Mode on and off.
Hi Team,Product Idea: Execution‑Rate Limits and User Verification Workflow for Plugin ActionsProblemPlugins can be triggered repeatedly within a short time window—either due to automation loops, misconfiguration, or unintended user behavior. When a Plugin executes more than an expected number of times in a defined period, it introduces risks such as:- Unintended system changes being applied repeatedly- Increased load on downstream systems- Potential security concerns if repeated execution indicates misuse or compromised credentials- Loss of user trust if actions occur without clear intentThere is currently no native mechanism in Moveworks to rate‑limit Plugin executions or to validate authenticity when abnormal execution patterns occur.Proposed CapabilityIntroduce a configurable execution‑limit framework for Plugins, allowing administrators to define:- Max execution count (e.g., 10 executions)- Time window (e.g., within 1 hour, 24 hours, etc.)- Trigger conditions (per user, per device, per workflow, or global)When the threshold is exceeded, Moveworks should automatically:- Pause further executions of the Plugin.- Notify the end user (or admin) that the Plugin has been triggered unusually often.- Request confirmation from the user to validate authenticity.- Resume or block execution based on the response. Regards,Sravani S
For now, the bot only proposes one button to reopen tickets, no matter what kind of ticket it is (incident, request, problem, task...). The button is called “Re-open issue”. This is not logical, because a simple request is not an issue.I propose we rename the button as “Re-open ticket” so that it is neutral and works with all kinds of tickets.
As a product owner/manager, I’m often presenting a roadshow deck to stakeholders at different levels of the organization. As Moveworks continues to evolve, it would be incredibly helpful to have a self-service repository of “default” architecture slides and marketing materials that we could pull from as needed. While I can always reach out to my CSM, having this content available on demand would make building internal decks much easier.
Reimagined setup experience for partners to configure ticketing with no friction.
We're experiencing several interception issues with the Copilot version of the bot, which has made the experience increasingly frustrating for the team. I’m documenting one such issue below for the product team to evaluate as a potential improvement opportunity.In the classic version, when the bot intercepted a ticket, it posted its full response along with the referenced KB article links directly in the ticket comments. This was extremely helpful, as it allowed us to:See which KBs were recommended to the user Track the bot’s response accuracy Take corrective actions by updating or improving the KBs based on user feedbackHowever, in the Copilot version, the bot only adds the answer summary in the ticket comment without any reference to the underlying KB sources. Since the bot is summarizing content from the top-ranked results, we have no visibility into which KBs were used to generate the response. This lack of transparency makes it difficult to validate or improve content quality.Moreover, we can’t depend on end users to manually share this information from their chat platforms each time—it’s neither scalable nor reliable.We’ve lost many of the valuable capabilities that the classic bot used to support, and this is affecting our ability to govern and improve content effectively.SuggestionInclude the source KB links or identifiers along with the bot’s response in the ticket comments, just as it worked in the classic version. This will improve traceability, content governance, and user trust in the system.
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
OKSorry, our virus scanner detected that this file isn't safe to download.
OK