Moveworks

Moveworks is a plausible fit for a large IT or employee-experience team that wants a conversational entry point for a narrow, repeatable service request and can operate it like a production integration. Its public material describes enterprise search, plugins and connectors, configurable assistants, IT support workflows, and an approach to verified ticket closure rather than mere routing. [S1][S2]

The practical buying question is not whether an agent can produce a good answer. It is whether the buyer can limit what the agent sees and changes, prove that each action was authorized and successful, and recover cleanly when it is wrong or a connector fails. Public sources do not establish those boundaries for a particular tenant, purchased product, or workflow. [S1][S2][S3]

Best for: Enterprise teams with a defined high-volume support request, maintained ITSM and identity systems, an accountable service owner, and capacity to test action controls, escalation, and recovery.

Not for: Organizations seeking an unattended replacement for IT ownership; teams without clean identity and service data; workflows that include privileged, destructive, safety-critical, or compliance-sensitive changes without proven approvals and manual fallback; or buyers unable to test the deployed tenant.

Close a bounded account-access request

• Trigger: An employee cannot access an approved account or asks for a routine, policy-defined access action.
• Inputs: Requester identity, authoritative entitlement and role data, target system, policy, action scope, approval rule, service record, and a constrained execution identity.
• Output: A verified action or a documented escalation. Moveworks uses account unlock/reset as an example of a workflow that can identify the user, act through an identity provider, confirm sign-in, and update the ticket. [S2]
• Human checkpoint: The service owner approves the supported request classes and risk boundary; an approver handles requests above that boundary; a technician receives all unresolved or low-confidence requests with context.
• Success measure: Verified closure rate, unauthorized-action rate, false-completion rate, reopens, recontacts, time to resolution, SLA attainment, escalation quality, and recovery time.

Resolve a routine IT request across systems

• Trigger: A high-volume request such as a software-access question, a basic VPN issue, or another pre-approved employee-support class reaches the assistant.
• Inputs: Request text, identity and authorization context, maintained runbook, selected knowledge sources, ITSM ticket, designated connectors, validation rule, and escalation queue.
• Output: A correct knowledge response, an executed and verified permitted action, or an enriched ticket for a human. The vendor distinguishes closure from merely categorizing, routing, or deflecting a request. [S2]
• Human checkpoint: ITSM and security owners define allowed actions, approvals, outcome checks, ticket-writing behavior, exception paths, and the human who can disable the workflow.
• Success measure: Closure by request class, reassignment rate, manual touches, end-to-end MTTR, SLA, backlog, safety exceptions, and total cost including review work.

Serve permission-aware IT knowledge

• Trigger: An employee asks for a policy, device, SaaS, access, or support answer that should not create a system change.
• Inputs: Selected knowledge sources, employee identity and permissions, current content owner, query, language requirement, and ticket or feedback path.
• Output: A context-aware answer or a route to human support. Moveworks says its platform uses connected knowledge, permissions, and enterprise search. [S1]
• Human checkpoint: Knowledge owners review source quality, access filtering, citations or source links where available, stale-content reports, and answers that could cause a user to take a risky action.
• Success measure: Correct-answer sampling, unsupported-answer rate, access-control failures, self-service completion, recontact, content-correction time, and deflection separately from verified resolution.

Configure a constrained custom agent

• Trigger: An IT team has a stable, measurable workflow that existing capabilities do not cover.
• Inputs: Approved business process, source and tool inventory, user allow list, prompts or configuration, required approvals, test cases, audit requirements, implementation owner, and rollback plan.
• Output: A tested internal assistant or agent available only to the approved group. The public platform page says builders can select sources, prebuilt plugins, and user allow lists, then test and publish approved assistants. [S1]
• Human checkpoint: The workflow owner, security and identity owners, service-desk owner, and change approver review testing, permissions, failure handling, and the release decision.
• Success measure: Completion accuracy, policy adherence, regression rate, override and escalation rate, unauthorized access or action, observability, implementation effort, and net benefit against the manual baseline.

1. An employee uses an available channel to ask for help. The buyer decides which populations, channels, languages, content sources, and request classes are in scope.
2. The assistant retrieves permitted context from selected systems and knowledge sources. It should not treat a retrieved article or a model-generated reply as evidence that a ticket is resolved. [S1][S2]
3. For an action workflow, a policy and identity check determine whether the request stays self-service, needs an approval, or must escalate. The workflow executes only through the authorized connector or execution identity.
4. The workflow verifies the intended outcome, documents the request and result in the service record, and notifies the employee. Moveworks treats permissioned action, validation, documentation, and notification as markers of closure. [S2]
5. A named IT owner reviews outcomes, reopens, errors, audit trails, source quality, and exceptions. The owner pauses or rolls back the workflow when evidence or controls no longer support safe operation.

Moveworks' public materials point to a useful model for buyer evaluation: test one request class that crosses a small number of well-understood systems, then compare verified closure and safety controls with the existing service process. The same connected-system design that enables useful action also creates risk when a connector has broad permissions, identity data is wrong, knowledge is stale, or a user is routed incorrectly.

Verified facts

• Moveworks describes a platform combining enterprise search, workflow automation, a Reasoning Engine, plugins/connectors, and tools to build assistants for IT and other functions. [S1]
• Its June 16, 2026 article differentiates a closed request from a routed or deflected one and identifies validated action, documentation, and notification as part of closure. [S2]
• ServiceNow's February 26, 2026 release says Moveworks remains available as a standalone product within the ServiceNow portfolio while EmployeeWorks combines Moveworks conversational AI and enterprise search with ServiceNow portal and workflow capabilities. [S3]
• Moveworks says it achieved ISO/IEC 42001 certification on May 27, 2026. [S4]
• The public pricing page directs buyers to request a custom quote rather than stating a public price. [S5]

Vendor claims

• Moveworks says its platform and agents can execute and verify cross-system requests within buyer-defined boundaries. This is a capability claim; test the exact action, connector, approval, and verification behavior in the buyer's tenant. [S1][S2]
• ServiceNow describes a Level 1 Service Desk AI Specialist for selected common IT work and said it was in controlled availability in February 2026. This is a product announcement, not proof of current general availability, buyer eligibility, accuracy, or outcomes. [S3]
• Moveworks says ISO/IEC 42001 reflects independently audited AI-governance controls. Obtain current evidence and scope rather than treating the announcement as a blanket assurance for the buyer's deployment. [S4]

B2Bagents assessment

Moveworks looks most useful where an IT organization is already able to run disciplined service workflows but needs a more accessible front door and controlled cross-system execution. Its public framing of closure—action, verification, documentation, and notification—is a better procurement test than counting chat answers or closed tickets. The platform should be treated as an operational system: value depends on the buyer's connectors, service design, access rules, knowledge quality, exception process, and sustained ownership, not the AI label.

• The reviewed sources do not establish which products, agents, connectors, plugins, models, channels, regions, data-residency options, support tiers, or action capabilities are included for a given buyer.
• Public material does not state the exact authorization design, execution identities, least-privilege scopes, audit-log retention and export, approval enforcement, data retention, deletion, incident terms, recovery behavior, or system-of-record rules for a buyer tenant.
• Public pricing is quote-based. Dollar price, pricing unit, overage, implementation, support, term, renewal, cancellation, transition, and service-level terms must be obtained in writing. [S5]
• A request can appear resolved when it was only answered, routed, or closed technically. Agentic workflows can also make a wrong, incomplete, stale, unauthorized, or irreversible action look plausible. [S2]
• The ISO announcement and platform badges do not substitute for current reports, scope, exceptions, buyer configuration, data-flow review, or contractual commitments. [S1][S4]

Good-fit conditions: one or more high-volume request classes; clear policy; authoritative identity and service data; well-maintained knowledge; narrow, reversible actions; available system owners; logged approvals; and a measured manual baseline.

Poor-fit conditions: broad privileged access; no action-owner or exception queue; inconsistent account and entitlement data; untested third-party connectors; unclear data rules; pressure to automate a workflow whose policy is disputed; or no manual way to complete the work when the agent fails.

Predictable failure modes and controls:

• An answer is treated as an outcome. Separate information responses, routed tickets, attempted actions, and verified closures; sample each class and track reopens and recontacts. [S2]
• An agent acts with the wrong identity or overbroad connector scope. Use separate least-privilege execution identities, test authorization changes and offboarding, require approvals where risk rises, and review access regularly.
• Stale or unauthorized knowledge informs an action. Assign a source owner, limit source scope, test access filtering and misleading content, capture feedback, and pause unsafe knowledge paths.
• A multi-step request fails between systems. Validate outcomes at each boundary, document partial state, provide technicians the request context and attempted actions, and test retry, rollback, and manual completion.
• A vendor statement or certification badge is mistaken for deployment assurance. Obtain current assurance materials and contract terms, map controls to the actual workflow, and test the buyer environment before broad use. [S1][S4]

Start with one low-risk, high-volume service class where action authority is clear: for example, a tightly bounded account-unlock flow or an approved knowledge-plus-ticket workflow. Avoid making the initial scope a broad access-provisioning, offboarding, privileged-admin, security-incident, production-change, or destructive-remediation system.

Name an IT service owner, workflow owner, identity owner, system owner for each connector, knowledge owner, security and privacy reviewer, tenant administrator, change approver, service-desk escalation owner, data owner, procurement owner, and incident contact. Moveworks describes implementation personnel, change management, custom development, sandbox setup, knowledge integrations, ongoing support, and migration services, but buyers should agree the actual delivery plan and responsibility split in writing. [S6]

For each connected system, document the connector, permissions, execution identity, authentication, approvals, input and output fields, rate limits, audit trail, error behavior, retry, rollback, disablement, credential revocation, data-retention and export behavior, and manual fallback. Treat a connector as a production integration, not a chat feature.

Moveworks' platform page displays security and compliance badges, and its May 2026 announcement says the company achieved ISO/IEC 42001 certification. These are useful starting points for diligence, not a conclusion that a specific configuration is compliant or safe. [S1][S4]

Before production, obtain current assurance materials and scope; the customer agreement, DPA, security schedules, subprocessor and model-provider list, data-flow diagram, retention/deletion terms, support-access model, residency options, encryption details, SSO/MFA/RBAC design, permission-mirroring or source-system authorization behavior, audit-log coverage and export, incident and breach procedures, business-continuity evidence, vulnerability-management process, and the commitments applicable to the purchased offering.

Run tenant-specific tests for requesters, managers, admins, service accounts, contractors, offboarded accounts, inaccessible sources, denied approvals, expired credentials, connector error, duplicate request, conflicting data, partial execution, false completion, forced escalation, audit retrieval, export, kill switch, and manual recovery. Do not let the agent process secrets, privileged data, regulated data, or high-impact changes unless the applicable contract, data flow, controls, and human authority are proved for that use case.

Moveworks publishes a request-a-quote path and says it offers scalable packages and flexible pricing; it does not publish a dollar amount or commercially sufficient detail to estimate the deployment. [S5]

Ask for a written proposal that separates product edition; agents and connectors; channels and environments; employee, workflow, API, action, data, or usage limits; implementation; migration; custom development; sandbox; training; support; security-review support; pilot terms; services; currency and taxes; renewal; price protection; cancellation; data export; deletion; and transition assistance. Price the operating model as well as the license: content upkeep, integration administration, security reviews, exception handling, approval work, service-desk escalation, and recovery are real costs.

1. Scope: Select one frequent, low-risk request with a well-understood policy, two or fewer connected systems, known owners, a narrow execution identity, and a manual fallback.
2. Baseline: Capture volume, current closure rate, manual touches, median and tail time to resolution, cost, SLA attainment, reopens, recontacts, escalation rate, exception age, user satisfaction, and safety incidents by request class.
3. Test set: Include correct and incorrect identity, missing entitlements, allowed and denied policy cases, stale knowledge, ambiguous request, low confidence, approval required, access denial, role change, offboarding, duplicate request, connector outage, partial action, failed verification, ticket-update failure, harmful embedded instruction, kill switch, rollback, audit export, and manual completion.
4. Pass threshold: Agree in advance on permission accuracy, correct-action rate, verified closure, evidence in the service record, escalation completeness, recovery time, no unauthorized or unreviewed high-risk actions, and a measurable net benefit after operator and control costs.
5. Stop conditions: Unauthorized access or action; an unverified action shown as complete; missing audit or approval evidence; unsafe source retrieval; connector or credential behavior the team cannot contain; inability to disable or recover; unacceptable error, recontact, or escalation rate; or no defensible improvement over the current process.

Compare Moveworks with the directory's Aisera, Atomicwork, Freshservice, SysAid, Atera, SuperOps, NinjaOne, Rewst, ConnectWise, and Serval profiles. The useful axes are whether the buyer needs employee-facing IT self-service, an ITSM layer, RMM or MSP operations, workflow automation, connector and identity scope, action authority, approval and audit behavior, deployment ownership, commercial model, and the evidence needed to count a request as closed.

1. Which purchased product and features are in scope? Obtain the current order form, entitlement matrix, release status, availability region, connectors, agents, channels, environments, limits, and support terms; do not infer them from a public product page. [S1][S3][S5]
2. What can the workflow actually read and change? Demonstrate the exact content and system scopes, execution identity, permission checks, approval route, verification, ticket update, audit record, failure case, kill switch, and manual fallback.
3. How does the platform prove a ticket is closed? Test an information response, a routed ticket, a successful action, a failed action, a partially completed action, a false-positive verification, a reopen, and a human escalation; report them separately. [S2]
4. Who owns failures and stale knowledge? Identify owners for each source, connector, workflow, approval policy, service queue, security issue, and customer-impacting incident, along with review cadence and change-control path.
5. What is the actual data and assurance position? Obtain current DPA, security schedules, ISO certificate scope, relevant reports, subprocessors, model use, retention/deletion, residency, support access, audit exports, and contractual incident obligations. [S1][S4]
6. What does the quote include and exclude? Get a written breakdown of subscription, usage limits, implementation, custom work, sandbox, training, support, services, renewal, cancellation, export, deletion, and transition assistance. [S5][S6]