Skip to main content

    986 Ideas

    Jared
    JaredInspiring

    Feature Request: Analytics for Proactive (“Pushed”) Bot Communications1. New

    Overview Currently, the platform’s analytics focus on user-initiated interactions with our Moveworks bot. However, as customer bots evolve to be more proactive—sending notifications and updates without direct user prompts—we lack visibility into the reach and effectiveness of these communications. To better understand the impact of bot-initiated messages, we propose the addition of analytics for proactive communications. This would provide insights into what types of messages are being sent, how frequently, and how users are engaging with them. Proposal: Implement Analytics for Bot-Initiated Messaging We request a new analytics capability to track and analyze any communication that originates from the bot, including but not limited to:• System-generated notifications (e.g., password reset alerts)• Employee communications tool messages• Creator Studio-initiated messages• Concierge or plugin-based notifications (e.g., ITSM status updates, comments)• External integration notifications (e.g., ITSM approval workflows) Key Metrics & Capabilities Requested:1. Message Volume Tracking – How many bot-initiated messages are being sent over time?2. Message Source Breakdown – Categorization by system, integration, or trigger type.3. Recipient Insights – Who is receiving these messages? Are certain groups more (or less) engaged than others?4. Engagement Metrics – How do users interact with bot-initiated messages? (e.g., click rates, dismissals, response rates)5. Impact Measurement – Correlation between notifications and user actions (e.g., did a status change notification lead to a follow-up inquiry?). Benefits:• Visibility – Understand the scale and scope of bot-initiated communications.• Optimization – Identify which messages are effective and refine strategies accordingly.• User Experience Improvement – Reduce notification fatigue by analyzing engagement trends.• Data-Driven Decision Making – Leverage insights to enhance proactive support efforts. By implementing analytics for proactive bot messaging, we can ensure that these communications are both meaningful and effective, ultimately improving the best possible user experience and the value of the Moveworks bot.

    glambInspiring

    Agent Studio 2.0 Timeout Limitations and Workflow Flexibility Compared to 1.03. Existing Functionality/Native Skill

    We’ve been working closely with Moveworks Support and Engineering and wanted to share some feedback regarding process timeouts in Agent Studio 2.0.Background:In Agent Studio Classic / 1.0, compound actions allow for asynchronous API calls. Each action within a compound action has a 60-second timeout, but there’s no overall timeout for the compound action itself. This has enabled us to build plugins that perform multiple API calls efficiently. In Agent Studio 2.0, conversational process replaces compound actions. However, the process is synchronous, and there’s a 60-second timeout for the entire conversational process.Issue: We’re encountering PLUGIN_ERROR_TIMEOUT in 2.0 like a user in this thread is experiencing:The suggested workaround from Moveworks Engineering is to use a compound action within the conversational process, allowing us to run actions asynchronously OR to just use compound action for the entirety of this plugin. We cannot optimize / use faster APIs to avoid timeout thresholds entirely due to our security architecture.Concern: While this workaround technically resolves the timeout issue, it seems to defeat the purpose of migrating to 2.0 for processes that require multiple long API calls. The synchronous nature of conversational processes in 2.0 limits us compared to the flexibility we had in 1.0. Additionally, if we need input validation of 2.0, then we must use conversational process + compound action which gets difficult to manage.Request: Is there any discussion internally of either increasing the timeout threshold beyond 60 seconds for conversational processes, or to enable (even specific actions within) conversational processes to be asynchronous? Currently, the main advantage we see in 2.0 is input validation, data types, and UI, while 1.0 remains more flexible for most workflow requirements.