Alerts Troubleshooting Guide

For each supported alert in Moveworks Setup, this guide explains why the alert appears, the common causes behind it, and the steps to resolve it.

Connector Alerts

Alert: Integration Failure – {System}

Description: The connection to {System} could not be established. This may be due to invalid or expired credentials, or a configuration issue.

Alert Type: System Alert
Module: Connector
Why it fires: Moveworks is unable to connect to {System} and can no longer fetch data from it.
Common causes:
1. Service-account credentials rotated in the external system without being updated in Moveworks Setup.
2. Service account locked, expired, or disabled at the source.
3. API permissions / scopes changed or revoked.
4. Source system unavailable or in an extended outage.
Troubleshooting steps:
1. Confirm whether the change is expected: did you recently rotate service-account credentials, change API permissions, or change the connector’s base URL?
2. Check that the credentials haven’t expired or been revoked, and still have the required roles and scopes.
3. Go to API Playground, select the failing connector, pick any API, and run it to review the response from the external system. Common response codes and what they mean:
  1. 401 Unauthorized: credentials are invalid or expired. Rotate credentials and update them in Moveworks Setup.
  2. 403 Forbidden: authentication succeeded but the credentials lack the required scopes. Verify roles and scopes in the external system.
  3. 404 Not Found: the endpoint or resource doesn’t exist. Verify the connector’s base URL and update if changed in the external system.
  4. 408 Request Timeout: the API request took too long. Retry after some time; if it persists, check the source system’s status page for any performance or availability issues.
  5. 502 Bad Gateway: an intermediate proxy or gateway at the source is failing. Wait and retry.
  6. 503 Service Unavailable: the source system is down or in maintenance. Check its status page.
  7. 504 Gateway Timeout: the source system is slow to respond. Wait and retry.
4. Ensure the connector has been set up following the Steps here
Potential Downstream Impact: Users, Knowledge, Account Access, Group Access, Employee Comms.

Alert: ServiceNow Service Account Timezone Mismatch

Description: The ServiceNow connector in Moveworks is using a service account with a timezone setting that does not match the expected options: ‘GMT’, ‘GMT0’, ‘UTC’, or ‘America/Danmarkshavn’.
Alert Type: System Alert
Module: Connector
Why it fires: The Moveworks service account in ServiceNow is set to a timezone that isn’t compatible with ticket polling.
Common causes:
1. The service account was created with the ServiceNow instance’s timezone other than ‘GMT’, ‘GMT0’, ‘UTC’, or ‘America/Danmarkshavn’.
2. Admin edited the service account and changed the timezone.
Troubleshooting steps:
1. Access your ServiceNow instance.
2. Click on All and type ‘Org’ in the search bar.
3. Select Users and locate your Service Account User.
4. Update the Timezone field to one of the specified options.
Potential Downstream Impact: In Ticketing > Ticket Polling would be unable to poll tickets due to the invalid timezone.

Alert: Chat Platform Credentials Expired

Description: The connection to {Chat System} could not be established. This issue may be due to invalid or expired credentials, insufficient permissions and scope, or a configuration issues.
Alert Type: System Alert
Module: Connector
Why it fires: The chat platform (Microsoft Teams or Slack) is rejecting the bot’s credentials, so the bot cannot post messages.
Common causes:
1. The bot’s client secret/bot token was rotated on the chat platform and not updated in Moveworks
2. The connector credentials have been expired
3. The bot application was revoked or its permissions changed
4. OAuth token refresh failed after a permission-scope change
Troubleshooting steps:
1. Navigate to Connectors > Built-in Connectors.
2. Select your {Chat System} Connector.
3. Update your credentials or adjust the connector configuration as needed.
4. Ensure that the connector’s scope and permissions are correctly set.
Potential Downstream Impact: Bot can’t reply to users.

Alert: Microsoft Teams – Message Authentication Failure

Description: The connection to {Chat System} could not be established. This issue may be due to invalid or expired credentials, insufficient permissions and scope, or a configuration issues.
Alert Type: System Alert
Module: Connector
Why it fires: Inbound messages from Microsoft Teams are failing authentication, so Moveworks cannot process them.
Common causes:
1. Signing keys or app credentials on the Teams side were rotated without updating in Moveworks.
2. Bot Framework app/manifest changes on the Teams side.
Troubleshooting steps:
1. Navigate to Connectors > Built-in Connectors
2. Select your MS Teams Connector
3. Update your credentials or adjust the connector configuration as needed.
4. Ensure that the connector’s scope and permissions are correctly set.
Potential Downstream Impact: Bot Unresponsive to user/users on the Chat Platform.

Alert: Microsoft Teams Installation Forbidden

Description: Failure to install bot in Microsoft Teams to subset of users.
Alert Type: System Alert
Module: Connector
Why it fires: Microsoft Teams is blocking the bot from being installed for a group of users, so those users can’t receive DMs from the bot.
Common causes:
1. The Teams app permission policy is blocking the Moveworks bot for the affected users, or custom apps are not included.
2. The bot app is missing one of the required Microsoft Graph permissions: User.Read.All or TeamsAppInstallation.ReadWriteSelfForUser.All
3. The Teams app GUID configured in Moveworks Setup no longer matches the app installed in the tenant, often because the bot was deleted and reinstalled, generating a new GUID.
4. The Microsoft Teams channel has not been enabled on the bot in Azure, or the bot configuration values (tenant ID, app ID, Teams app GUID) in Moveworks Setup are incorrect.
5. A conditional access policy, Microsoft Purview app governance rule, or Teams app blocklist restricts the Moveworks bot from being installed for the affected users.
Troubleshooting steps:
1. Have your Microsoft Teams Admin confirm the bot is assigned and authorized for the necessary permissions (User.Read.All and TeamsAppInstallation.ReadWriteSelfForUser.All)
2. Review the app permission policy settings for the bot.
3. Verify that the bot has not been blocked or restricted by organizational policies.
Potential Downstream Impact: Microsoft Teams — bot installation blocked for some users.

Chat Platform Alerts

Alert: Bot has been disabled by admin

Description: The bot has been disabled and is unable to send messages to users and/or users may be unable to locate the bot in their chat client. Please reach out to your Microsoft Teams admin to get the bot re-enabled in your Teams admin console. This may also require modifying the app’s Permission Policy.
Alert Type: External Alert
Module: Chat
Why it fires: The bot has been disabled in the chat platform, so users can’t message it or find it in their client.
Common causes:
1. Microsoft Teams admin disabled or blocked the bot in the Teams admin console.
2. The bot was removed from the app permission policy that applies to end users.
3. App governance/lifecycle policy auto-blocked the bot.
Troubleshooting steps: Contact your Microsoft Teams admin to re-enable the bot in the Teams admin console. This may also require modifying the app’s permission policy.
Potential Downstream Impact: Bot unavailable to users in the chat interaction platform.

User Identity Alerts

Alert: User validation failed: significant change in user records

Description: Current user count {Y} differs by over {X%} from the previous ingestion ({Z}). Please verify if this change is expected or check for potential issues in your data source or configuration.
Alert Type: System Alert
Module: User Identity
Why it fires: The total number of users in the latest ingestion is significantly less from the previous one.
Common causes:
1. Configuration change: the primary connector for User Identity was removed or switched, or the user filter was changed, resulting in fewer users being returned.
2. External system change: a large number of users were removed at the source or made inactive.
3. Connector issue: credentials expired or permissions were revoked.
4. Source-system issue: the external system was temporarily unavailable or timed out while fetching the users
Troubleshooting steps:
1. Check the external system: In your primary identity system (Okta, AD, etc.), compare its active user count against the count shown in the alert.
  1. If the source system shows a similar count, the change originated in the source system. Review the following in the source system:
    1. Users deactivated or removed
    2. Users moved to an inactive or suspended status that the connector filters out
    3. A joining-key change (such as an email domain migration) that prevents Moveworks from recognizing those users
    4. A change to the filter that determines which users are ingested (e.g., group membership, active status, or organizational unit).
  2. If the source system shows more users than the alert, the ingestion is missing users. Proceed to step 2 to check the connector.
2. Check the connector in Moveworks Setup: in the API Playground, run the “list users” call for the primary identity connector. If the call fails or returns no users, the connector is not fetching data. Update the credentials in Moveworks Setup (Connectors > Built-in Connectors), or grant the connector the required scope in the external system.
3. Check for identity configuration changes: Was the primary identity connector changed? Were user filters modified?
4. Confirm the change is expected: if either of the above changes was intentional, click Override to accept the new baseline.
Potential Downstream Impact: Import Users, Ticketing, Knowledge Search, File Search, Account Access, Group Access, Employee Comms.

Alert: User validation failed: significant change in user record IDs

Description: A significant drop of {X%} has been detected in the user attribute “{department}” since the previous ingestion, impacting {Y} of {Z} users. Please verify if this change is expected or investigate potential issues in your data source, or configuration.
Alert Type: System Alert
Module: User Identity
Why it fires: A large set of the record IDs Moveworks ingested previously are missing in the current crawl. Even though the connector may be returning a similar number of users, those users now carry different unique identifiers.
Common causes:
1. Identity mapping change: the record ID source attribute in Moveworks Setup was changed to a different source field (e.g., from employeeId to WID), so every user now maps to a new record ID.
2. Primary identity connector switched: the primary identity connector was changed (e.g., Okta → Azure Directory). The new connector uses a different identifier system, so users are now recognized under different IDs.
3. Source system reassigned identifiers: the external system reset or reassigned identifiers across users, often during a tenant migration, identity provider consolidation, or bulk re-provisioning.
4. Primary identity connector switched: the primary identity connector was changed (e.g., Okta → AD). The new connector uses a different identifier system, so users are now recognized under different IDs.
5. Source system reassigned identifiers: the external system reset or reassigned identifiers across users, often during a tenant migration, or bulk re-provisioning.
Troubleshooting steps:
1. Check for identity configuration changes in Moveworks Setup:
  1. Was the record ID source attribute in your identity mapping changed recently (e.g., from employeeId to WID)?
  2. Was the primary identity connector switched?
2. Check the source system:
  1. Did the external system undergo a major change that reassigned identifiers, such as a tenant migration, or bulk user re-provisioning? Confirm with your IDAM team if you’re unsure.
  2. Were users recreated with new IDs (e.g., account cleanup or re-provisioning)
  3. The identifier field being read (Okta id, MS Graph id, Workday WID, etc.) was reset
3. Confirm the change is expected: if either of the above changes was intentional, click Override to accept the new baseline.
Potential Downstream Impact: Import Users, Ticketing, Knowledge Search, File Search, Account Access, Group Access, Employee Comms.

Alert: User validation failed: significant drop detected in user attributes

Description: A significant drop of {X}% has been detected in the user attribute “{field_name}” since the previous ingestion. Please verify if this change is expected or investigate potential issues in your data source or configuration.
Alert Type: System Alert
Module: User Identity
Why it fires: A specific user attribute (such as email, manager, department, or a custom field) is now missing for significantly more users than before, even if the total user count is unchanged.
Common causes:
1. Configuration change: the source-attribute mapping for the affected field was updated in Moveworks Setup
2. External system change: the source system stopped populating this attribute for a large set of users
Troubleshooting steps:
1. Check the affected attribute in the source system: for the field name in the alert (e.g., manager, department, email), look up a sample of users for whom it’s not populated.
  - If the attribute is empty or missing at the source, the change originated in the source system. Common triggers:
    1. The field was deprecated, renamed, or made optional at the source.
    2. Users were re-provisioned without this attribute populated.
    3. A bulk migration or cleanup cleared the field for many users.
2. Check the attribute mapping in Moveworks Setup: was the source-attribute mapping for changed recently? For e.g. was email remapped from mail to userPrincipalName
Potential Downstream Impact: Import Users, Ticketing, Knowledge Search, File Search, Account Access, Group Access, Employee Comms.

Alert: User validation failed: duplicate user records detected

Description: A total of {X%} of users ({Y} of {Z}) have conflicting identity mappings (e.g., record ID, email). Please ensure there are no duplicate users in the external system and that identity attributes are unique and consistently mapped across records. Additionally, review your configuration for any inconsistencies.
Alert Type: System Alert
Module: User Identity
Why it fires: More than 5% of ingested users share the same lookup identifier (such as email, chat ID, or ITSM ID) with another user. Because Moveworks uses these identifiers to link users across systems, duplicates prevent Moveworks from reliably identifying users.
Common causes:
1. Duplicate accounts at the source: two accounts in the same source system share the same identifier
2. Manual user management: a user was manually added or edited in Moveworks Setup with attributes (ITSM or chat channel IDs) that overlap with a user ingested from external system, producing two records with the same lookup identifier but different record IDs.
Troubleshooting steps:
1. Check for common duplicate patterns at the source:
  1. Reactivated ex-employee accounts colliding with a current employee (email reuse).
  2. Shared inboxes or service accounts using an employee’s email.
  3. Two accounts (e.g., a primary and an admin account) created with the same identifier.
2. Check for manually managed users in Moveworks Setup: if any user or service account was manually added or edited in Moveworks Setup, verify that their identifiers (email, chat ID, ITSM ID) do not overlap with a user being ingested from an external system.
3. Resolve the duplicates: deactivate or merge the duplicate accounts at the source, correct or remove any conflicting manually managed users, or update the service account configuration, so that every lookup identifier is unique across users.
Potential Downstream Impact: Import Users, Ticketing, Knowledge Search, File Search, Account Access, Group Access, Employee Comms.

Alert: User validation failed: schema validation error

Description: Attribute data-type/ schema error has been detected for {system.attribute}. Please review source attribute mapping of your configured identity sources to resolve this.

Alert Type: System Alert
Module: User Identity
Why it fires: One or more user attributes are being returned by the source in a shape or format that Moveworks cannot ingest.
Common causes:
1. Source system change: an attribute’s data type or format changed at the source – for e.g. a field expected as a string is now returning an object, or an ID doesn’t match the expected format for its integration.
2. Attribute mapping issue in Moveworks Setup: a custom attribute or ID mapping was updated to point at a source field that returns a value in a different type or format than expected.
3. Data quality issue at the source: a subset of users have incorrect or missing values in a required field (e.g., empty IDs, incorrect ID formats, unexpected null values).
Troubleshooting steps:
1. Identify the failing attributes: review the failed_attributes field in the alert.
2. Check the affected attribute in the source system: for each failing attribute, look up a sample of affected users and inspect the raw value in the source system.
  - If the value is empty, malformed, or in the wrong data type, the change originated at the source. Common triggers:
    1. The source system changed the attribute’s data type or format.
    2. The field was renamed or replaced with a similar field of different semantics.
    3. Bad data was introduced through a bulk migration or update.
  - If the value looks correct at the source, the issue is in the mapping. Proceed to step 3.
3. Check the attribute mapping in Moveworks Setup: verify the source-attribute mapping for the failing field. Was the mapping recently changed to point at a different source field, or is it referencing a field whose data shape has changed?
4. Resolve the issue: correct malformed values at the source system, or update the mapping in Moveworks Setup so the declared type matches what the source now returns.
Potential Downstream Impact: Import Users, Ticketing, Knowledge Search, File Search, Account Access, Group Access, Employee Comms.

Alert: 0 users ingested

Description: 0 users ingested. Please review your external system, connector scope, and identity configuration to resolve this.
Alert Type: System Alert
Module: User Identity
Why it fires: No users were ingested into the Moveworks platform in the latest ingestion run. Because Moveworks requires a user roster to function, ingestion is blocked until at least one user is successfully ingested.

Common causes:
1. Connector authentication or scope issue: the connector can authenticate but does not have permission to read users from the external system
2. Missing joining key values: the joining key value (typically email) is empty for users at the primary identity system, so Moveworks cannot identify and merge them properly.
3. User filter mismatch: the User Identity filter in Moveworks filtered out all users from the external system.
4. Connector misconfiguration: the primary identity connector is pointing at the wrong environment, where no users exist.
5. Source system unavailability: the source system is returning empty responses due to an misconfiguration on its side.
6. No active users at the source: the external system has no active users to ingest

Troubleshooting steps:
1. Verify users and joining keys are populated in the source system:
2. Check the connector via API Playground: in the API Playground, run the “list users” call for the primary identity connector. Interpret the response:
  - 401 / 403: credentials or permissions issue. Update the credentials in Moveworks Setup (Connectors > Built-in Connectors), or grant the connector the required scopes in the external system.
  - 5xx or timeout: the source system is unavailable. Wait and retry, or check the source system’s status page.
  - 200 with an empty response: the source returned no users. Proceed to step 3 to check the connector configuration.
3. Check the production instance: is the connector pointing at the correct environment (for e.g. production, not a sandbox instance)? Correct if needed.
4. User Identity filter: was the filter narrowed to a value that excludes all users (e.g., a department, group, or organizational unit that no longer exists)? If so, please widen or correct the filter as needed.
Potential Downstream Impact: Import Users, Ticketing, Knowledge Search, File Search, Account Access, Group Access, Employee Comms.

Alert: Record uniqueness condition failed

Description: A total of {X} user records share the same unique identifier. Please ensure each user record has a unique record ID and remove any duplicate records from the external system. Additionally, review your configuration for any inconsistencies.
Alert Type: System Alert
Module: User Identity
Why it fires: Two or more user records share the same record ID, the primary identifier Moveworks uses to distinguish users.
Common causes:
1. Non-unique attribute mapped as record ID: the source attribute used as the record ID is not guaranteed to be unique across users
2. Duplicate values in the source system: two or more user records at the source have the same value in the field mapped as the record ID, due to a data-quality issue or a source-system bug.
3. Manual user management conflict: a user manually added or edited in Moveworks Setup was assigned a record ID that also belongs to a user ingested from an automatic connector.
Troubleshooting steps:
1. Identify the colliding record IDs: review the alert details for the duplicate count. Locate the specific record IDs that are duplicated (by inspecting the ingested users)
2. Check the source-attribute mapping for the record ID: in Moveworks Setup, verify which source field is mapped as the record ID.
  1. If the mapped field is not guaranteed to be unique (e.g., employeeId, email), change the record ID mapping to a source attribute that is truly unique
  2. If the mapped field is expected to be unique but the source is still returning duplicates, proceed to step 3.
3. Check the source system for duplicate values: Look up the colliding record IDs and confirm whether multiple users share the same value in that field. If two accounts share the value, deactivate, merge, or update the accounts so the record ID field is unique across users.
4. Check for manually managed users in Moveworks Setup: if any user was manually added or edited in Moveworks Setup, verify that their record ID does not overlap with a user ingested from an automatic connector.
Potential Downstream Impact: Import Users, Ticketing, Knowledge Search, File Search, Account Access, Group Access, Employee Comms.

Alert: User Identity Ingestion failed

Description: User Identity Ingestion failed, so your user data couldn’t be refreshed and may be stale. Please verify your identity configuration.
Alert Type: System Alert
Module: User Identity
Why it fires: A step in the user identity pipeline failed before a final user profile could be built, while fetching, mapping, processing, merging users and subsequent steps (validation runs after this and is covered separately towards the end).
- For background, check how user identity configuration works within Moveworks Setup.
Troubleshooting steps:
1. Validate the connection at source. Go to Moveworks Setup → Core Platform → Data Ingestion → Data Crawling and look for any system showing a failed or incomplete sync. To see exactly why, open the API Playground, select the failing connector, and run its Get All Users action. Read the response code:
  - 401 / 403 — credentials expired or missing permissions. Reconnect the source or refresh its credentials.
  - 400 / 404 — wrong API URL or user filter. Recheck the connector setup.
  - Timeouts / 429 / 5xx — the source is slow or down (for on-prem AD / LDAP, check the VPN or tunnel). Usually temporary.
  - 200 with 0 users — an empty source is treated as a failure. Loosen the filter or fix the group it points to.
2. Your source specific field mappings. In MoveworksSetup → User Identity → Identity Configuration → Configure source mapping, review the field mapping. Ingestion fails here when a mapping can’t be applied at all — usually a custom expression that returns the wrong type for the field it fills (for example: returning an integer when a string is expected). Test the expression against a sample user, then preview the final profile to confirm it builds. A mapping that points to a field which doesn’t exist just leaves it blank — that does not fail ingestion.
3. Your joining keys (only if you pull users from more than one source). In MoveworksSetup → User Identity → Identity Configuration → Set Joining Keys, confirm there is exactly one primary source with a joining-key value for every user, and that the key points to the same identifier in every system.
4. Validation failures. If the failure is at the validation stage (after the profile is built), go through the User identity validation alerts doc for detailed troubleshooting steps.
5. If the failing step is not clear, and the source, mappings, and joining keys all look right, contact Moveworks support with the alert name and timestamp.
Potential Downstream Impact: Import Users, Ticketing, Knowledge Search, File Search, Account Access, Group Access, Employee Comms.

Forms Alerts

Alert: Forms validation failed: significant drop detected in {forms}

Description: Current forms ({X}) have decreased by {Y%} compared to the previous ingestion ({Z}), with {M} items removed. Please verify if this change is expected or check for potential issues in your data source or configuration.
Alert Type: System Alert
Module: Forms
Why it fires: The number of forms in the latest ingestion is significantly lower than the previous one.
Common causes:
1. Forms catalog deleted.
2. Forms archived, disabled, or deleted in bulk at the source.
3. Connector scope narrowed to fewer projects, catalogs, or workspaces.
4. A “published only” / “active only” filter added or its meaning changed at the source.
5. Forms source system unavailable, returning a partial catalog.
Troubleshooting steps:
1. Check the external system: Filter the forms system to the projects, catalogs, or workspaces the connector is scoped to and count active forms.
2. Check the connector in Moveworks Setup: In the API Playground, run the list-forms call and confirm the count matches what Moveworks ingested.
3. Check for configuration changes: Was the forms connector scope, published / active filter, or downstream forms filter
Potential Downstream Impact: New or existing forms may not surface in the Moveworks Assistant.

Alert: Forms validation failed: significant drop detected in {form field options}

Description: Current form field options ({X}) have decreased by {Y%} compared to the previous ingestion ({Z}), with {M} items removed. Please verify if this change is expected or check for potential issues in your data source or configuration.
Alert Type: System Alert
Module: Forms
Why it fires: The dropdown / picklist options on ingested forms have decreased significantly from the previous ingestion run.
Common causes:
1. Picklist cleaned up (inactive options removed) at the source.
2. Reference table (department list, category list, location list) migrated or restructured.
3. A form field changed from picklist to free-text.
4. An ‘active options only’ filter was applied at the source system, excluding inactive options from the API response.
5. Form-field mapping changed to a different field with fewer values.
Troubleshooting steps:
1. Check the external system: Open the specific picklists and confirm the active option count. Check whether options are “inactive” rather than deleted.
2. Check the connector in Moveworks Setup: In the API Playground, fetch a form definition and count the options in each picklist.
3. Check for configuration changes: Was the form-field mapping changed? Was an “active options only” filter added in the external system?
Potential Downstream Impact: Updated form field options will not be reflected in Moveworks forms.

Groups Alerts

Alert: Group Ingestion Failure

Description: Group Ingestion data is stale due to a downstream error or other restriction such as Large Data Change Protection being triggered.
Alert Type: System Alert
Module: Access Groups
Why it fires: The number of groups in the latest ingestion is significantly lower than the previous one or there’s another downstream underlying issue.
Common causes:
1. Connector missing required scopes (e.g. Group.Read.All on MS Graph, admin-level group read on Okta).
2. Service-account role changed, removing group-read permission.
3. IDAM source system unavailable.
4. Group filter narrowed to match no groups.
5. Large Data Change Protection: an unusually large change to the group set was detected and ingestion was paused pending approval.
Troubleshooting steps:
- Verify the connector has the right scopes and the credentials are correct.
- Check with your IDAM team if there are issues with the source system.
- Email Moveworks Support to mark the ingestion as approved if it is due to a Large Data Change Protection alert.
Potential Downstream Impact: Groups leveraged in the Access DL skill may not be able to discover new Groups.

Alert: Group Ingestion Failure

Description: Issues importing Groups into Moveworks.
Alert Type: System Alert
Module: Access Groups
Why it fires: Group ingestion has been failing, so newly created or updated may not be discoverable.
Common causes:
1. Connector missing required scopes (e.g. Group.Read.All on MS Graph, admin-level group read on Okta).
2. Service-account role changed, removing group-read permission.
3. IDAM source system unavailable.
4. Group filter narrowed to match no groups.
Troubleshooting steps:
- Verify the connector has the right scopes and the credentials are correct.
- Check with your IDAM team if there are issues with the source system.
Potential Downstream Impact: Groups leveraged in the Access DL skill may not be able to discover new Groups.

Knowledge Alerts

Alert: Knowledge Ingestion – Large drop in articles

Description: A significant (>50%) decrease in the number of ingested articles has been detected.
Alert Type: Configuration Alert
Module: Knowledge
Why it fires: A large portion of knowledge articles are missing from the latest ingestion. Ingestion is blocked until the change is verified or approved.
Common causes:
1. Intentional configuration change (new folder/space scope, new filters excluding articles, or bulk archival).
2. Knowledge source system incident or partial outage.
3. Connector creds expired or scopes changed so entire content is no longer available.
4. Content team migrated articles to a different space that isn’t ingested.
Troubleshooting steps:
1. If this drop is expected, contact Moveworks Support and request: “Mark ingestion of knowledge articles as healthy despite large data drop”.
2. Check for intentional configuration changes (new filters, changed folder scopes, archiving/deleting content).
3. Verify source-system health — ensure the external data source is online and accessible.
4. Check connector permissions — confirm the Moveworks service account or API credential still has the correct access scopes.
Potential Downstream Impact: Internal Knowledge would have a gap in content.

Alert: Knowledge Ingestion Failure

Description: Knowledge data is stale due to a downstream error or other restriction such as Large Data Change Protection being triggered.
Alert Type: System Alert
Module: Knowledge
Why it fires: Knowledge ingestion has been failing, so stale content is being served to users.
Common causes:
1. Connector credentials rotated / revoked; scopes changed.
2. Source system unavailable.
3. Large Data Change Protection triggered.
4. Rate limits at the source system.
Troubleshooting steps:
1. Verify the connector has the right scopes and the credentials are correct.
2. Check with your Knowledge team if there are issues with the specific system.
3. Navigate to Core Platform > Customer Data Crawling to view the knowledge ingestion, click View Logs for further info, and review the Error Summary.
4. Email Moveworks Support to mark the ingestion as approved if it is due to a Large Data Change Protection alert.
Potential Downstream Impact: The Moveworks AI Assistant will not be able to answer questions related to new content.

Ticketing Alerts

Alert: Ticketing - Tickets are not passing the Universal ticket filter

Description: No tickets have passed universal filter. Check ticket filters (particularly Universal ticket fetching filter)
Alert Type: Ticketing Filter Alert
Module: Ticketing
Why it fires: No tickets are matching the Universal ticket filter, preventing downstream ticketing skills (polling, actions, interception) from receiving any tickets to process.
Common causes:
1. Universal filter clause tightened (added AND condition, narrowed a field match).
2. Field referenced in the filter was renamed or removed at the source.
3. Ticketing source system stopped emitting the fields the filter matches on.
4. Filter operators / values were changed and now match no tickets in practice.
Troubleshooting steps: Review your ticket filter configuration (particularly the Universal ticket fetching filter).
Potential Downstream Impact: Ticketing, Ticket Actions, Ticket Polling, Ticket Interception.

Permissions Alerts

Alert: ServiceNow Permissions Data Stale

Description: Moveworks ServiceNow User Criteria Crawl is failing.
Alert Type: System Alert
Module: Permissions
Why it fires: Moveworks can’t successfully crawl user-criteria data from ServiceNow.
Common causes:
1. The Moveworks ACL update set was not installed (or was uninstalled) in ServiceNow.
2. The moveworks_user role is not granted to the Moveworks service account.
3. Service-account credentials expired or lost the required permissions.
4. The connector is not properly configured for user-criteria ingestion.
Troubleshooting steps:
1. Verify the ServiceNow connector is properly configured.
2. Verify the Moveworks ACL update set is properly installed.
3. Confirm the moveworks_user role in ServiceNow is granted to the Moveworks service account.
4. After confirming the above, file a Moveworks Support ticket.
Potential Downstream Impact: ServiceNow Knowledge may not serve to users.

Agent Alerts

Alert: Agent disconnected

Description: There are no Moveworks on-prem agents connected.
Alert Type: External Alert
Module: On-Prem Agent
Why it fires: No Moveworks on-prem agents are currently connected, affecting downstream skills
Common causes:
1. The host running the agent restarted or crashed.
2. Firewall or egress-proxy changes are blocking the agent’s outbound connection.
3. SSL certificate expired or was rotated without updating the agent.
4. DNS changes prevent the agent from resolving Moveworks endpoints.
5. Agent credentials were rotated or revoked.
6. Agent process was stopped and not restarted.
Troubleshooting steps:
1. Verify whether the server hosting the agent has failed or restarted recently.
2. Check whether firewall settings have changed recently.
3. Ensure that all necessary SSL certificates are valid and present.
4. Confirm that DNS settings are correctly resolving Moveworks system addresses.
5. Verify whether the agent credentials are valid. Please follow this detailed Troubleshooting Guide for Resolution.
Potential Downstream Impact: Import Users, Account Access, Group Access, Employee Comms