Getting StartedSupport

Ensuring your bot is always available

View as Markdown

Introduction

The Moveworks bot is installed as a bot application in Enterprise Chat Platforms such as Slack, Microsoft Teams, or Google Hangouts Chat. While the details of the installation vary from platform to platform, there are some common rules to follow that will help keep your bot and its various skills available and running without service interruption or service degradation. This document provides an overview of specific changes that require notifying the Moveworks team in advance to ensure that the changes will not affect the availability or performance of the bot. During the Moveworks deployment, your Implementation team has configured the Moveworks Platform based on the current configurations of the systems that Moveworks is integrating with. Therefore, if there are any planned changes to these systems, it is critical that you provide your Moveworks Implementation team at least three business days before executing the change(s) so that the team can verify that the change will not have any impact on the bot.

Ground Rules for Uninterrupted Bot Service

In most installations, the bot relies on connections to following IT systems.
Messaging Platform (Slack, Microsoft Teams, Skype for Business, or Google Hangouts Chat) ITSM Ticketing System (Salesforce Service Cloud, ServiceNow, Jira Service Desk, FreshDesk) Identity and Access Management Systems (Active Directory, Okta, Ping, Duo) Knowledge Base Platform (ServiceNow Knowledge Management, Microsoft SharePoint, Guru Knowledge, Confluence, or your FAQ repository saved on a cloud drive or local drive)

In the following sections, we outline types of changes and examples that could affect the availability or performance of the bot.

General Changes:

Changes in this category are applicable to any system that Moveworks integrates with. Admins of systems that are integrated with Moveworks should be aware that the following changes may affect the bot, and provide the Moveworks team sufficient notice before performing these change

Networking Changes:

  • Server address changes including domain name changes or server address changes
  • Firewall rules or ACLs changes on the corporate network
  • Network routing changes
  • CASB changes

Data center infrastructure changes:

  • Moving any system to the cloud or into an on-prem data center.
  • System Version / server upgrades
    • e.g: Significant Version Upgrades, On-Prem -> Cloud Migrations
  • Cert Changes - Adding a new CA. or renewing certs due to renewal or any other purposes.

Service Account Changes

  • Renaming service account and/or changing service account credentials
  • Modifying the default timezone of any service account (needs to always be GMT)
  • Turning on MFA for service accounts
  • Expiration of service account credentials.
  • Clawback of Account Licenses and/or Access Permissions
    • The bot typically relies on a licensed service account on your ITSM platform. Make sure that automatic clawback of licenses does not entirely remove the bot’s access to your system, or other modifications change access to specific fields or tables.
    • Your Moveworks Implementation team also typically has a contractor/vendor account in your systems, please ensure this account stays active and does not lose relevant licenses (e.g ITIL License).

Identity & Access Management / Application and Group Provisioning:

Changes in this category are applicable to Identity & Access Management systems, which includes integrations with Okta, Active Directory/LDAP, OneLogin, etc.. Admins of Identity & Access Management systems should be aware that the following changes may affect the bot, and provide the Moveworks team sufficient notice before performing these changes:

  • Changes to Password Expiration or Account Unlock Policies
  • Active Directory OU Structure Changes
  • Software Group ID or Group Name Changes
  • Email Domain / Tenant Migrations
  • e.g: Migration from company.com to company-corp.com
  • On-Prem to Cloud Migrations

ITSM Systems

Changes in this category are applicable to ITSM systems which includes systems like Zendesk, Fresh Service, Cherwell, ServiceNow, Jira Service Desk, etc. Admins of ITSM systems should be aware that the following changes may affect the bot, and provide the Moveworks team sufficient notice before performing these changes:

  • Changes to mandatory fields on creation, comment, closure
  • Addition of business rules/other policies that restrict actions.
    • e.g: Only users in a certain assignment group can close a ticket.
  • Changes in workflow transitions
  • Changes to Service Portal URL for key Service Portal views
    • e.g: Catalog Item URL, Ticket View URL, Approvals URL
  • Large scale additions or removals of values the bot is triaging, such as Category, Subcategory, Assignment Group or other fields.
    • By default the bot will be retrained and pick up new fields on a monthly cadence, but if you are making any changes to important assignment groups, or large scale changes, we recommend giving your Moveworks Implementation Team a weeks notice.
  • Migration to using custom fields for business logic.
  • Service Catalog Redesign or Reorganization
  • Changes to Request Type IDs or Backend API Schemas
    • Modifying or recreating Request Types can change underlying unique IDs. Since Moveworks relies on these IDs for ticket filing, any backend structural changes require an update to the Moveworks configuration to prevent filing failures.
  • Changes to Service Accounts as outlined above

Knowledge Systems

Changes in this category are applicable to Knowledge Base Platforms & Intranets, which includes systems like Confluence, ServiceNow, Jive, Igloo, Guru, Simpplr, etc. Admins of these platforms should be aware that the following changes may affect the bot, and provide the Moveworks team sufficient notice before performing these changes:

  • Changes in Site organization
  • Changes in Page Hierarchy
  • Changes in Site Name
  • Changes in Knowledge Base Article/Site URL link format
  • Changes in Site, Knowledge Base, or Knowledge Article Permissions
  • Introduction of significant changes to knowledge/site templates and formatting.
    • e.g: introduction of new Custom CSS to templates

Chat Platforms

Changes in this category are applicable to Chat Platforms, which includes systems like Microsoft Teams, Slack, Facebook Workplace, Google Hangouts Chat, Ringcentral Glip, etc. Admins of these platforms should be aware that the following changes may affect the bot, and provide the Moveworks team sufficient notice before performing these changes:

  • Migration or Upgrade of chat system
    • e.g: Migration from Slack Business to Slack Grid
  • Deleting, Modifying, or Reinstalling the bot application
    • This includes any external use of the Bot values (Eg: use of Bot ID in a different App)
  • Chat App Policy changes:
    • e.g: Who can view the bot, chat retention
  • Changing ownership of the bot application
  • Termination of the Bot App Owner’s account

Managing Connector Credentials

Credential Security:

  • Store credentials in a secrets manager — Never save service account passwords in plain text (e.g., a spreadsheet or email). Use a dedicated secrets manager such as HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or your company’s approved password manager. Restrict access to only the team members responsible for managing the Moveworks integration.
  • Use a shared team vault, not personal accounts — Store credentials in a shared organizational vault rather than an individual’s personal password manager. This prevents loss of access if the original admin leaves the team.

Credential Expiry & Proactive Renewal:

  • Know your expiry policies before you set up — Before configuring each connector, check the password/token expiry policy for that system (e.g., ServiceNow, Okta, Azure AD). Document the expiry date alongside the integration in your internal runbook.
  • Set a calendar reminder 30 days before expiry — When credentials are created or rotated, immediately create a recurring calendar event (or ticketing system task) for 30 days prior to the expiry date. Assign it to the team distribution list — not a single individual — so it doesn’t get missed due to PTO or role changes. Title it clearly, e.g.: “ACTION REQUIRED: Rotate Moveworks [ServiceNow/Okta/etc.] service account credentials before [date]”.
  • Rotate credentials before they expire — not after — Expired credentials will cause Moveworks to lose connectivity to that system connector, interrupting user-facing capabilities (ticket creation, roster sync, automated actions) without warning. Proactive rotation avoids unplanned outages.
  • Update Moveworks Setup immediately after rotation — After rotating a credential in the source system, update the corresponding connector in Moveworks Setup → Manage Connectors right away. Validate the connector is healthy before closing the change ticket.
  • Use non-expiring tokens where your system allows it — Some systems (e.g., ServiceNow) support non-expiring API tokens for service accounts. Where your organization’s security policy permits it, prefer these over short-lived passwords to reduce operational overhead and outage risk.

Contacting Us

To notify the Moveworks team of significant changes, please email support@moveworks.ai with details about the change, and when it is occurring. Also, flag the change to your Moveworks Implementation team so they can assess if immediate support is required to prevent an outage.