Skip to main content

    Filter by idea status

    Filter by product

    1344 Ideas

    dhorvathCommunity Manager

    ServiceNow Flows & Actions in Moveworks5. Controlled Availability

    What is ServiceNow Flows & Actions in Moveworks?ServiceNow customers have built years—often decades—of business logic and automation using Flow Designer, Workflow Studio, actions, and subflows. This capability makes those existing ServiceNow automations available as execution tools for Moveworks agents.Rather than rebuilding the same logic in a separate system, teams can expose selected ServiceNow actions and subflows through a ServiceNow MCP server. The Moveworks Assistant can then invoke those tools as part of a conversational request, while the underlying automation continues to run in ServiceNow.AvailabilityThis capability depends on MCP Workspace, which will provide the Moveworks-side experience for configuring and managing MCP connections and tools.  How it worksAn administrator configures an MCP server in ServiceNow using MCP Platform Manager. The administrator registers the appropriate Flow Designer actions and subflows as MCP tools. Moveworks connects to the ServiceNow MCP server and makes the approved tools available to its agents. When a user's request requires an action, the Moveworks agent invokes the relevant ServiceNow tool and presents the result in the conversation.ServiceNow supports creating MCP tools from both Flow Designer actions and subflows.What can users do?The available experiences depend on the automations each organization chooses to expose. Example requests could include:“Register Tempo Analytics as a new business application.” “Start the employee offboarding workflow for this contractor.” “Request approval to add this application to the software catalog.” “Provision the standard development environment for my new engineer.” “Run the approved remediation flow for this configuration item.” “Create the application record and route it to the correct owner for approval.”For example, an existing ServiceNow flow could check whether an application already exists, create or update the appropriate records, route an approval request, and notify the relevant teams. The employee initiates the request in Moveworks, while ServiceNow remains the system executing the established workflow.Why it mattersReuse existing investments: Extend ServiceNow automations your organization has already designed, governed, and tested. Avoid duplicate development: Make existing actions and subflows available to Moveworks agents instead of recreating their logic elsewhere. Bring execution into conversation: Let employees initiate complex workflows using natural language in the Moveworks Assistant. Keep administration in ServiceNow: ServiceNow administrators choose which automations become MCP tools and how those tools are configured.Configuration and requirementsAdministrators will configure the ServiceNow MCP server and select the actions and subflows that should be exposed as tools. Individual tools must meet ServiceNow's compatibility, input/output, and access-control requirements.This capability uses MCP to connect Moveworks agents to the tools configured in the customer's ServiceNow instance. Additional resourcesServiceNow MCP Platform Manager Create a tool from an Action Create a tool from a Subflow

    Indrashis
    IndrashisCommunity Manager

    Data Crawling Updates for Migrated Content Connectors6. Delivered

    What changesMigrated content connectors appear under Content (new architecture) in Moveworks Setup → Data Ingestion → Data Crawling. As these connectors move to the new ingestion architecture, their troubleshooting view changes to failed API request counts and a View Failed Logs action.The updated view helps administrators investigate failed source-system requests. It is an interim monitoring experience and does not provide the previous full-refresh and incremental run history or an overall crawl-health assessment.AvailabilityThe updated view is released. Content (new architecture) appears automatically for connectors after they are migrated to the new ingestion architecture for your organization. The connector migration determines when you see the section; you do not need to enable the view yourself.Your organization may have connectors under both Content and Content (new architecture) while migrations continue. Follow the instructions for the section where your connector appears.How to investigate a failed requestOpen Data Crawling in Moveworks Setup and expand Content (new architecture) using View Crawls.Locate your connector under the relevant resource group and select View Failed Logs.Review the Timestamp, Error Code, Error Message, and API Request. Filter by error code to narrow the results.Use the request details to investigate source-system access or configuration with your administrator. Contact Moveworks Support if the issue remains unexplained.What the view can and cannot tell youCrawl Health displays Not applicable. This means the section does not provide a crawl-health assessment; it is not a Healthy or Unhealthy result. Full-refresh and incremental run charts, individual run details, and per-run record inspection are unavailable in this view.Failure counts represent logged API-request events. Multiple entries can refer to the same endpoint or problem. Counts do not measure missing documents or unique unresolved issues, and historical failures may not describe the connector's current state.An empty failed-request table does not establish complete or current ingestion. Use the existing record-level inspection tools in Control Center to investigate a particular article or file. Contact Moveworks Support for unresolved questions about missing or stale content.Customer actionYou do not need to recreate your connectors or move them between sections. For connectors that appear under Content (new architecture), use the updated failed-request investigation workflow. Connectors under Content continue to use the existing run-based monitoring experience.DocumentationSee the Data Crawling View documentation.

    Derrick
    DerrickInspiring

    UI-Based On-Prem Agent Service Management1. New

    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.