If a view is empty for you but fine for a colleague, or Azure DevOps returns "TF400813: The user is not authorized to access this resource", the cause is usually your access level rather than anything in the extension or your project configuration. This is the single most common support question we see, and the fix takes an administrator about a minute.
What is actually happening
Azure DevOps has three access levels: Stakeholder, Basic, and Basic + Test Plans. Stakeholder is free and deliberately limited — it is designed for people who need to view and add work items and see dashboards, not for people who query work item data in bulk. Reading the underlying work item data that any analytics tool depends on requires the Basic access level. That is a Microsoft licensing boundary, not a restriction the extension imposes, and it applies identically to every Marketplace analytics extension.
How to tell this is what you are hitting
Three signals, and you usually have more than one:
- A colleague sees the same view populated and you do not — the difference is your account, not the project
- The error mentions TF400813, or "not authorized to access this resource"
- Workflow mapping cannot read your project's states, and the extension offers to let you map them manually instead
What to ask your administrator for
Send them this: "Please raise my Azure DevOps access level from Stakeholder to Basic." They will find it under Organization settings → Users, by selecting your account and changing the access level. Reload the extension afterwards — no reinstall, and none of your configuration is lost.
Will that cost anything?
Possibly not. Azure DevOps includes a number of Basic seats at no additional cost in every organisation — at the time of writing Microsoft covers the first five — and many organisations have unused ones. Your administrator can see what is available under Organization settings → Billing. Worth checking before assuming a purchase is needed, and worth confirming against Microsoft's current terms rather than taking our word for it.
What the extension does in the meantime
It tells you, rather than showing you an empty chart and letting you conclude the product is broken. Where Azure DevOps refuses a read because of the access level, the message names the likely cause and what to ask for. Where workflow states cannot be read, you can still map them by hand and keep going. And in our own telemetry these refusals are graded as a configuration issue rather than a fault, so they do not sit in our bug queue pretending to be something they are not.
If your access level is already Basic and a view is still empty, that is worth reporting — it is then genuinely our problem, not a permissions one. Ask Henry from the top bar in the extension and a real person will reply within one business day.
Related: Documentation