Build better products with our product team.
ProblemToday, configuring a new service for an on-prem Moveworks Agent requires administrators to obtain server access, manually modify the agent configuration file, and restart the Docker container. This creates operational overhead, requires elevated permissions, and increases the risk of configuration errors.Additionally, when an agent is upgraded through the Moveworks UI, the version displayed in the underlying configuration file does not appear to be updated, creating potential confusion when troubleshooting or validating deployed versions.Proposed EnhancementExtend the On-Prem Agent management experience to allow administrators to:Add, edit, and remove service configurations directly through the Moveworks UI. Validate configuration settings before deployment. Apply configuration changes without requiring manual file edits or direct server access. View the effective running configuration and deployed agent version from a single interface.Additional ImprovementEnsure agent upgrades performed through the UI update all version references consistently, including any version information stored within the agent configuration files, so administrators can easily verify the currently deployed version.Business ValueReduces the need for sudo/server access. Eliminates manual configuration file maintenance. Lowers risk of configuration errors and deployment inconsistencies. Improves operational efficiency and supportability. Provides a more complete self-service administration experience for on-prem agent management.
I am having trouble getting an account of what event triggers are used as I can not find that information on the csv export file. Though the interactions can be looked at in detail through Data API, my team is looking for alternatives to Snowflake for sustained reporting. In order to get an account as to how many times a plugin is used as an event trigger and to verify correlation with the Analytics Overview dashboard, I propose adding an Event Trigger Used column to the Interactions report.
Key DatesFrontier: September 2 2026Standard: September 8 2026Basic: September 10 2026Learn more about our model upgrades here.We’re upgrading the AI Assistant’s toxicity filtering to consider the full context of a conversation rather than evaluating content in isolation. This provides a more accurate understanding of user intent and helps identify genuinely harmful content. The upgrade also reduces false positives, allowing safe conversations to continue without unnecessary interruption. Administrators can review the configuration steps for more information: https://help.moveworks.com/agent-studio/agentic-ai/conversational-safeguards-assistant/configure-moveworks-toxcity-filter#configuration-steps
How are we improving the product?Managed service providers (MSPs) often serve multiple customers through a single domain-separated ServiceNow instance, where each customer’s data is partitioned into a separate domain. EmployeeWorks does not support this deployment model today.This initiative will help MSPs extend EmployeeWorks to customers within shared, domain-separated ServiceNow environments.What is included in this milestone?This milestone adds domain-level filtering for the ServiceNow connector within Moveworks. This enables the connector to operate within the intended customer domain when connecting Moveworks to an MSP’s shared ServiceNow instance.Future milestones may expand support for domain-separated deployment models.
How are we improving the product?ServiceNow customers will have a ready-to-use EmployeeWorks instance available on day one.Automated configuration synchronization from ServiceNow to EmployeeWorks will establish the required baseline configuration, reducing manual onboarding work and helping customers get started faster with a consistent setup.How does it work?Required EmployeeWorks configurations are synchronized from ServiceNow.New customers receive an EmployeeWorks instance with the baseline configuration already available.Existing AI-native customers will be migrated using internal tooling operated by FDEs.Customer impactCustomers will spend less time waiting for manual configuration and can begin onboarding with a prepared EmployeeWorks environment.
How are we improving the product?Moveworks is introducing Configuration APIs to help enterprise teams move configurations safely across environments such as DEV → UAT → Production.This provides a controlled, repeatable alternative to manually recreating configuration in every organization. It also allows teams to incorporate Moveworks configuration changes into their existing source-control, review, and CI/CD processes.How does it work?Two APIs enable the configuration promotion workflow:Export API: Exports an organization’s complete configuration as a single manifest that can be stored, versioned, and reviewed.Apply API: Compares the manifest with a target organization and adds, updates, or removes configuration to bring the target into alignment.Teams can preview the proposed additions, updates, and deletions before applying them. Apply operations are validated and atomic—they either complete fully or make no changes.Technical restrictionsPromotion applies to configuration only, not customer or user data.Credentials and secrets are not included in exported manifests and must be managed separately in each organization.The target organization must pass configuration and reference validation before changes can be applied.Licensing and documentationLicensing requirements and public documentation will be added before General Availability.
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.
When a plugin action runs in the background (e.g. creating a record or sending a confirmation), Moveworks briefly pauses the model while it waits for the result. On GPT-5.4, that pause could sometimes cause the model to run the same action a second time instead of waiting — creating duplicate side effects. We rewrote the instruction the model receives during that wait so it clearly understands the result is still coming and should not retry.
Updating our Reasoning Engine to GPT 5.4.
Employee Communications campaign interactions (e.g., button clicks like "Good to know!") currently do not have a Conversation Topic assigned, which causes them to log with a <nil> value in the Conversation Topic field.In Analytics, this is inflating the <nil> Topic bucket in gap/intent-failure reporting — these interactions are being counted as unresolved or ambiguous intents (or in some cases appearing to overlap with feedback-related records), when in reality they are simply acknowledgment button clicks tied to Employee Comms campaigns. This isn't limited to "Good to know!" — any Employee Comms campaign button (e.g., "Reclaim my license" for a license-reclaim campaign) would log the same way, since none of these interactions currently receive a Conversation Topic.Request: Assign a dedicated Conversation Topic value (e.g., "Employee Communications") to all Employee Comms campaign interactions, regardless of the specific button/CTA text used. This would let customers reliably filter/exclude these interactions from gap analysis and other Analytics reporting, rather than having them fall into <nil> and skew intent-failure metrics.
Hi Moveworks Community,I’d like to suggest a usability improvement for Agent Studio.When working with multiple open items — such as Conversation Actions, Conversation Processes, and HTTP Actions — the top tab bar can quickly run out of space. Once many tabs are open, it becomes difficult to navigate between them because there doesn’t seem to be a clear way to scroll horizontally through all open tabs.Would it be possible to add a horizontal slider, scrollbar, or another tab navigation mechanism at the top, so users can easily move across all open CA, CP, and Action tabs?This would be especially helpful when building or debugging complex workflows with many related components open at the same time.Thanks!
Description: Dear Team,I would like to understand whether Moveworks currently provides any native capabilities within the Control Center, or via API, for the following monitoring and alerting requirements. Additionally, if any of these capabilities are already available, please let us know whether they are currently being utilized by any customer.1. Outage Monitoring and VisibilityOutage Notifications: Immediate alerts when the bot, or any of its critical connected integrations, experiences downtime.Root Cause Visibility: Detailed logs indicating what failed, when the outage started, and which specific service, system, or connector was impacted.Historical Uptime Tracking: Access to historical uptime data and incident logs for reporting and audit purposes.2. Integration Credential Expiration AlertsServiceNow: Proactive notifications (for example, 30/15/7 days in advance) for expiring service account passwords or API tokens.Microsoft Graph: Expiration monitoring for Azure AD / Entra ID client secrets and tokens used by the bot.3. Certificate and Key Lifecycle ManagementAWS Certificates: Monitoring and alerting for AWS infrastructure certificates, specifically in the Corning environment.JWT and JWKS Keys: Alerts for upcoming expiration of JSON Web Tokens (JWTs) or keys used for custom API authentication and SSO.4. Alerting and Notification ChannelsThe ability to route these notifications through preferred enterprise channels, such as:Automatic ITSM incident creationEmail notifications to the admin teamWebhook-based alerts to Slack or Microsoft TeamsRequest for ClarificationCould you please confirm:Whether any of the above capabilities are currently available natively within Moveworks Control Center;Whether they can be accessed, configured, or exposed via API;Whether any customers are currently using these capabilities; andIf not currently available, whether this can be considered a formal feature enhancement request for the product team.Thank you for your support. I look forward to your guidance.
What’s changing?Moveworks is introducing a dedicated Users experience in the Troubleshooting Hub within Moveworks Setup. It will give admins and partners a central place to monitor user identity ingestion and investigate issues without switching between multiple tools or relying on Moveworks teams for routine diagnosis.The experience will include:Ingestion health at a glance: See the latest ingestion status, fetched and indexed user counts, and scheduled run information.User-level investigation: Search for individual users and understand why a user may be missing, excluded, or dropped during ingestion.Clear issue identification: Surface connector, configuration, processing, and partial-ingestion issues affecting user identity data.Guided troubleshooting: Review customer-friendly explanations, likely root causes, recommended actions, and links to relevant configurations.Centralized workflow: Move from identifying an ingestion problem to investigating and resolving it within one experience in Moveworks Setup.These changes are designed to help admins and implementation partners validate that user data is current and complete, identify ingestion problems earlier, and resolve common issues with less reliance on Moveworks Support.
What’s changing?Triage configuration is moving into a single, guided experience in Moveworks Setup. Instead of configuring metadata, fields, model training, rollout controls, and output guardrails across disconnected pages, admins will be able to manage the Triage setup journey in one place.The simplified experience will include:Unified setup journey: Configure prerequisites, choose fields, train the model, and manage outputs through one guided flow.One source of truth for shared settings: Manage rollout mode, delivery method, ticket eligibility, and analytics settings without duplicating configuration across multiple pages.Inline validation and safer defaults: Review ticket scope before training and use built-in guardrails to prevent invalid lookback windows or confidence settings.Clearer model controls: Set confidence thresholds, rollout behavior, allowlists, blocklists, and default values after reviewing model performance.Prediction insights: Use visual insights to understand model quality and make informed decisions about which predictions to allow or block.Optional overrides: Add deterministic heuristic rules only when needed, rather than configuring them for every Triage field.These changes are designed to reduce configuration errors, shorten setup cycles, and make Triage easier for admins and implementation partners to configure, validate, and maintain without extensive Moveworks assistance.
How are we improving the product?New Moveworks admins can now follow a guided journey from the Moveworks Setup Overview page. Instead of navigating the platform without a clear starting point, admins receive an organized sequence of foundational setup activities with the context and resources needed to get started.The Getting Started guide helps admins understand what to configure, how long each activity may take, and where to find detailed guidance—making initial setup easier to navigate and reducing uncertainty during onboarding.How does it work?Admins in organizations that are still onboarding see a Getting started? banner on the Moveworks Setup Overview page.Opening the guide displays the recommended setup journey organized into sections and steps.Each step includes a description, an estimated completion time, and a link to relevant documentation.Admins can select Start to go directly to the appropriate configuration area in Moveworks Setup.Section navigation helps admins move through the journey and understand the broader setup process.Licensing restrictionsThis capability is available to customers with access to Moveworks Setup. Users must have the appropriate administrative permissions to access and complete configuration activities.Technical restrictionsThe Getting started? banner is shown only for organizations that are in the onboarding stage.The guide does not currently track or display completion status for individual setup steps.The guide provides recommended navigation and resources; the exact configuration work and prerequisites vary by organization and integration.DocumentationLearn more about the guided setup journey in the Moveworks Setup Getting Started Guide.
How are we improving the product?Admins can now delete 10 additional configuration types directly in Moveworks Setup. This makes it easier to clean up test or unused configurations after implementations, migrations, and environment cutovers without filing a support request.The expanded deletion experience includes dependency checks where applicable and configuration-specific warnings to help admins understand the impact before completing a permanent action.How does it work?Self-service deletion is available for these additional configuration types:ConnectorsSSOChatbotUser IdentityFormsSoftware AccessLive Agent HandoffPermission RulesMirror PermissionsChannel ResolverOpen the supported configuration in Moveworks Setup and select Delete.Review the warning describing the impact of deleting that configuration.When applicable, Moveworks checks whether other configurations depend on it. If references exist, deletion is blocked until those dependencies are removed.Confirm the deletion to permanently remove the configuration.Licensing restrictionsThis capability is available to customers with access to Moveworks Setup. Users must have the appropriate administrative permissions to manage and delete configurations.Technical restrictionsDeletion is permanent and cannot be undone.User Identity and SSO configurations can only be deleted in non-live organizations.The default Web chatbot cannot be deleted.Connectors with active configuration dependencies cannot be deleted until those references are removed.After deleting a connector, its name cannot be reused.Additional restrictions may apply depending on the configuration type and its references.DocumentationLearn how configuration deletion works, including supported types, dependency checks, and safeguards, in the Configuration Delete documentation.
How are we improving the product?Validation failures can block user and form ingestion when Moveworks detects an unexpected data change. Previously, admins and implementation partners had limited context about what failed and often needed help from Moveworks teams to validate expected changes.Self-Serve Validation Failure Alerts bring detailed, actionable alerts into Moveworks Setup. Admins and partners can understand the affected resource, review why validation failed, and resolve supported failures directly—reducing implementation delays and reliance on support.How does it work?When a supported user or form ingestion validation fails, Moveworks creates an alert in Moveworks Setup with details about the change and its impact.The admin or partner reviews the alert and determines whether the data change was expected.For supported expected changes, they can override the validation failure, provide a justification, and confirm the action.If the change was unexpected, they can use the troubleshooting guidance to identify and fix the underlying configuration, permission, credential, or source-data issue.Override actions are recorded for auditability, and future validation runs use the accepted data as the new baseline.Licensing restrictionsThis capability is available to customers with access to Moveworks Setup. Users must have the appropriate administrative permissions to review and resolve alerts.Technical restrictionsThe initial self-serve override scope covers supported validation failures for user identity and forms ingestion.Not every validation failure can be overridden. Alerts that indicate unsafe or invalid data must be corrected through troubleshooting.An override confirms that the detected change is expected and cannot restore the previously indexed data.DocumentationLearn how to investigate validation alerts and resolve common causes in the Moveworks Setup Alerts Troubleshooting Guide.
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.