We have identified a fix that allows us to map the unexpected user IDs to the known user IDs. We plan to have this fix deployed on Monday and will check in with affected customers.
Posted Mar 14, 2026 - 09:05 CET
Update
We can see through our logs that users are loading data sets at the same rate as normal. This tells us that the service degradation is limited to a small subset of customers. For customers that are impacted, the impact is major as they are not able to access their data sets or store new data sets. The legacy data loader is still usable.
All customers who experience issues should contact us via support@55degrees.se so we can investigate what may have changed with IDs in their ADO instance. When we understand what has changed we should be able to work with the customer to resolve the problem. When we see a pattern we hope be able to update the app to support these changes without support intervention in the future.
Until we see this pattern we will leave this incident in the status "Investigating" and we have reclassified this incident as "Degraded Performance".
Thank you for your patience.
Posted Mar 13, 2026 - 13:44 CET
Update
We are continuing to investigate the issue and how widely users are affected. It now seems likely that this issue is only affecting users in ADO instances that had changes to their identity management and thus have new user IDs rather than an underlying system issue. However, we are still verifying this. We will keep you updated as information emerges and we identify the underlying problem.
Posted Mar 13, 2026 - 13:00 CET
Update
We are continuing to investigate the best way to solve the issue. Thank you for your patience.
Posted Mar 13, 2026 - 11:21 CET
Update
We are investigating to see how many customers this affects. While we started with the more safe assumption that all users are impacted, it may be that only a portion of our users are impacted. We have published a banner inside the application to let users know that their ability to see their saved data sets may be impacted.
We will provide an update as soon as we have more information.
Posted Mar 13, 2026 - 09:59 CET
Investigating
We are currently investigating an issue caused by a change in Azure DevOps Services user identifiers. This change introduced an additional user ID format that our system did not previously recognize. As a result, users were not correctly mapped to their subscriptions or saved data sets.
Customer Impact
Users were initially unable to access their subscriptions in the app. As a temporary mitigation, we disabled subscription authorization checks, allowing users to continue accessing the product. While this restored general access, saved data sets remain inaccessible because the new user ID is not yet mapped to existing user records.
Current Mitigation
To minimize disruption, subscription authorization checks have been temporarily overridden, allowing users to access the application without subscription validation. However, users still cannot access their data sets once they access the app.
Root Cause (Under Investigation)
Our system currently supports two Azure DevOps user ID formats and includes logic to map users correctly regardless of which identifier is returned by the Azure DevOps APIs.
Based on our investigation so far, Azure DevOps is now returning a third user ID format for each user. Because this identifier is not currently recognized by our mapping logic, affected users are not associated with their existing subscriptions or saved data sets.
Resolution in Progress
We are actively implementing a fix to:
- Support the newly returned Azure DevOps user ID - Restore correct user-to-subscription and user-to-data-set mappings - Reinstate normal authorization checks
Next Update
We will provide an update as soon as a fix is deployed or additional information becomes available.
Posted Mar 13, 2026 - 09:50 CET
This incident affects: ActionableAgile for Azure DevOps Services.