Moveworks outage history

We have identified an issue affecting Tool Studio admins. Admins are seeing a “You do not have the role needed to perform this action” error when creating or updating connectors, and Script Actions in Agent Studio are failing to load, even though their permissions are configured correctly. Our engineering team is investigating the root cause and actively working on a fix. We don’t have a workaround yet, and we will share the next update as soon as we have more information. Impacted Regions: All

We are continuing to work on a fix for this issue.

A fix has been implemented and we are monitoring the results.

This incident has been resolved.

We have identified an issue where some users are noticing duplication of Employee Communications campaign messages on Microsoft Teams. Messages continued to be delivered multiple times even after campaigns were cancelled, resulting in a degraded user experience. We sincerely apologize for the inconvenience.

We learned that some users also experienced intermittent delays and "thinking" messages in the Moveworks Assistant on Microsoft Teams due to the same underlying issue. We have now applied a mitigation and are actively monitoring the results. Thank you for your patience.

This incident has been resolved as of 12:10 PM PST.

We're investigating an issue affecting the Moveworks Assistant in Microsoft Teams. Users report the bot entering a "thinking" state with no response. In some cases, users are not receiving responses as expected. We are actively working on resolving this issue and will provide updates shortly. We apologize for the inconvenience caused.

We are continuing to investigate and identify a mitigation. We sincerely apologize for the ongoing disruption.

A fix has been implemented and we are monitoring the results.

This incident has been resolved.

We are investigating an issue affecting a small number of users of the Moveworks Assistant on the EmployeeWorks web app. Impacted users may receive the message "Looks like I am having some trouble responding to you now..." in response to their requests. The large majority of conversations are unaffected. Our engineering team has identified the component involved and is actively working on a fix. We will share another update as soon as remediation is underway or when we have more information. We apologize for the inconvenience and appreciate your patience.

We are continuing to work on a fix for this issue.

Our engineering team has identified a likely cause of the intermittent error responses affecting a small number of users of the Moveworks Assistant on the EmployeeWorks web app. We applied a configuration change and we have not observed the error since then. We are continuing to monitor the results through the end of the day to confirm the issue is fully resolved. We will share another update once we have confirmed the fix or if we have more information.

This incident has been resolved.

We're aware of an issue where some users can't load the Agent Studio plugins page. They see the message "You do not have the role needed to perform this action." The issue affects users without Super Admin access in some orgs. We've identified the cause, and a fix is being deployed now. We'll share an update once it's resolved. Thanks for your patience.

A fix has been implemented and we are monitoring the results.

This incident has been resolved.

We have identified an expired SSL certificate affecting access to Moveworks Academy. Users may encounter a browser security warning that prevents them from accessing the site. The issue has been escalated to the relevant team for certificate renewal. We will share further updates as they become available.

We are continuing to work with the relevant team to restore access to academy.moveworks.com. We apologize for the inconvenience.

We have rotated the SSL certificate and confirmed that access to Moveworks Academy has been restored. Users should now be able to access the site without browser security warnings. Thank you for your patience.

We are investigating an issue preventing scheduled knowledge ingestion jobs from running in the US region. As a result, the latest content may be delayed in being ingested. We apologize for the inconvenience. The Assistant remains available and functional. Other regions are unaffected.

A fix has been deployed and we are currently monitoring the results.

This incident has been resolved.

We are investigating an issue where any utterance that is identified as a greeting fails to render the help options on the Get Help page, leaving users unable to file a ticket or connect to a live agent. The Get Help tab opens but shows only the Chat Summary with no handoff options presented. We apologize for the inconvenience this is causing your users. Impacted Regions: All

We have identified that this is impacting customers on the Frontier and Standard tiers of the Model Upgrade program. We are actively working on a fix and will provide further updates shortly.

A fix has been deployed and the Get Help options are now rendering as expected for all messages. Thank you for your patience, and apologies again for the disruption.

We are investigating an issue where users are not able to log in to the My Moveworks portal. We will keep you posted on the progress we make. We apologise for the inconvenience in the meantime.

A fix has been implemented, and we are monitoring the results.

This incident has been resolved.

We have been seeing issues with a few users being unable to send messages to the Assistant on Teams. They see the chat bar being greyed out, which shows a message: "You cannot send messages to this bot". We are investigating the issue and are also working with Microsoft internally. At a high level, it looks like a policy update has blocked this bot from being accessible. We will keep you posted on the updates.

Workaround Available We have identified that, for some affected customers, the Available to setting for the Moveworks bot in the Microsoft Teams admin centre is set to No one. Restoring the appropriate availability has resolved the issue for some customers. Teams administrators can update this setting by following these steps: 1. Sign in to the Microsoft Teams admin centre. 2. Go to Teams apps → Manage apps and select the Moveworks bot. 3. Open the Users and groups tab. Alternatively, select No one (org-wide default) if it appears as a link. 4. Under Availability, select Edit availability. 5. Change Available to from No one to one of the following: Everyone — Select this if all users in the tenant should have access to the bot. This is the most common setting for Moveworks deployments. Specific users or groups — Select this to restrict access to particular security groups, Microsoft 365 groups, dynamic membership groups, or distribution lists. Search for and add the required users or groups. 6. Select Apply to save the change. Microsoft advises that availability changes can take up to 24 hours to apply to all users and, in rare cases, up to six days to appear in the Teams client. However, the change may take effect sooner. We are continuing to investigate the underlying cause and will provide further updates as more information becomes available.

This incident has been resolved. Anyone still affected can follow the workaround steps shared previously.

We are seeing intermittent failures on outbound calls to Microsoft Teams, which may result in the Assistant not responding in Teams. There is currently an elevated volume of reported Microsoft Teams issues, and we are actively investigating whether this is the cause. Impact: Assistant messages in Microsoft Teams may intermittently fail to deliver, and users may not receive a reply. Impacted regions: All We will keep you posted with further updates.

Error rates on outbound calls to Microsoft Teams are declining and the Assistant is responding normally for most requests. We are continuing to monitor to confirm full recovery.

The intermittent unresponsiveness of the AI Assistant in Microsoft Teams has been resolved. Responses have returned to normal, and we have confirmed stability through continued monitoring. No further action is required from customers.

We're investigating an active issue where end users in Microsoft Teams are seeing the default Moveworks logo instead of their organization's custom bot logo, despite a custom icon being set in the app manifest. This appears to affect the bots published via the Teams App Store (store auth) rather than a single tenant. Logging out/back in or clearing the Teams cache resolves it for some users. Our engineering team is actively investigating and we will share more details as they become available.

We have escalated this issue to Microsoft and are actively working with their team to address the issue. We will provide more details when they are available.

Microsoft has identified the root cause as a platform regression affecting app branding display in Teams. A mitigation has been deployed and is currently rolling out. Microsoft's engineering team continues to monitor the rollout and validate the fix. Users may see the correct custom logo restored as the mitigation propagates. No action is required on your side. We will continue to monitor and will share additional updates as progress continues.

Microsoft's mitigation continues to roll out and we are monitoring propagation. Most users should see the correct custom logo restored. If any users are still seeing the default Moveworks logo, please capture a HAR file while reproducing the issue and share it with Moveworks Support. We will share additional updates as progress continues.

Issue summary and resolution details from Microsoft: Issue: Some published Teams apps briefly displayed the app publisher's default icon instead of the custom icon/branding configured by the tenant admin. Root Cause: A recent platform change to how bot-based interactions authenticate could, in certain cross-tenant request paths, cause the service to look up the tenant's data in the wrong geographic region. When that lookup did not resolve, the service temporarily cached an incomplete view of the tenant's app-customization settings. While that cached view was in effect, affected apps fell back to the publisher's default icon rather than the configured custom branding. The actual configuration was never lost — it remained correct in the source of record; only the temporary cached copy was incomplete. Onset timeframe: Introduced with the bot PFT/POP rollout in the July timeframe. Exact rollout start/ramp dates are being confirmed with the partner team that owns the rollout. Resolution: We have corrected the region-resolution logic so tenant-specific data is always looked up using the tenant's own region, preventing the incomplete cached state. The fix is rolling out through our standard deployment pipeline. As caches refresh, affected apps return to displaying the configured custom icons automatically, with no action required on the customer's side. Customer impact / data safety: Display-only regression. No configuration was changed or lost, and there was no impact to data security or access control. Mitigation timeline: • Code review / validation complete: Thursday EOD (9/11) • Server-side fix deployed via regular deployment process: 9/24 • Client cache refresh (~24 hours after server deployment): +24h • Fully reflected for customers: 9/25 Recovery is automatic as caches refresh post-deployment; no action is required from the customer.

The fix should now be reflected for everyone, allowing the incident to be closed out.

We identified an issue affecting multiple customers where approval requests were processed successfully, but users encountered a “You don’t have access to the request” error when retrieving the updated record. Engineering has deployed a fix and is currently monitoring the system to ensure stability. We will share additional updates as they become available.

This incident has been resolved.

We have identified authentication failures affecting SharePoint Online integrations that use Microsoft App Store authentication, following Microsoft’s deprecation of the legacy ACS authentication method. As a result, legacy SharePoint knowledge ingestion will fail for affected customers. As an immediate workaround, please follow the SharePoint Online Azure App Registration guide. https://docs.moveworks.com/service-management/access-requirements/knowledge-base-systems/sharepoint-online-access-requirements-new-1#1-configure-azure-app-registration Engineering is working on a JWT-based update for Microsoft App Store authentication. We will share additional updates as they become available.

Our documentation site is currently down; we are working with the vendor to get it back up and running. We sincerely apologise for the inconvenience in the meantime.

The fix has been implemented, the site is loading fine now, and we are continuing to monitor it.

This incident has been resolved.

We identified an issue with CSAT surveys not going out for the mentioned week. We identified the issue and have fixed it; subsequent CSAT's should run as usual. We sincerely apologise for the inconvenience caused.

We are investigating reports of false alerts regarding connector credential expiry across multiple customer instances. What's happening: Some customers are receiving notifications that their connector credentials have expired or are invalid. Our investigation confirms that affected connectors are functioning normally and successfully authenticating. Impact: No service impact. All connectors are functioning normally and authenticating successfully. The alerts being triggered are false positives due to an ongoing backend issue. What we're doing: Our engineering team is actively investigating and working on a resolution. What you should do: If you see a connector credential expiry alert, please make an API call using the connector in API Playground to validate your credentials. If you receive a successful response, your connector credentials are working fine and no action is required. We'll notify you when this is fully resolved. We apologize for the confusion. Thank you for your patience.

This incident has been resolved.

We're aware of an issue affecting Moveworks Setup where logs are currently not loading, and our team is actively investigating. We apologize for the inconvenience. Impacted Region: US

Our engineering team has resolved the issue. Logs in Moveworks Setup are now loading as expected. Thank you for your patience, and apologies again for the inconvenience.

We have identified an issue affecting the testing of compound actions in Agent Studio, where users may see a "Failed to process custom action" error. A fix is currently being deployed. This issue is limited to the testing experience only — compound actions already running in the assistant are not affected. We'll share another update once the fix has been rolled out and verified.

A fix has been implemented and we are monitoring the results.

This incident has been resolved

Permissions ingestion has been failing for Unily connectors. This is due to Unily deprecating their Permissions API, we are working with them to find a way forward. We will keep you posted on the progress. Until then, the newly added or updated permissions won't be ingested. We sincerely apologise for the inconvenience caused.

Unily has confirmed a fix is being packaged. Once it's available, customers will need to upgrade to the patched version. We encourage impacted customers to reach out to Unily directly, and we'll share more details as we have them.

This incident has been resolved.