Moveworks has a partial disruption.

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.

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.

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.

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.

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.