Administering Agile Analytics for your team
What happens automatically on install, how to roll out to your team, and how access, seats, organisation defaults and the admin activity log actually work under the hood. Written for whoever ends up answering “who can see what” questions.
1. Install & first run
Two things happen automatically the moment the right person opens the extension for the first time. Nothing else is configured for you.
What happens automatically
- The installing admin becomes admin automatically
The first person to open the Hub who is an Azure DevOps Project or Organization Administrator is claimed as the extension admin silently, with no button to click. This only happens once — an org that already has an admin is never touched.
- Workflow mapping seeds itself on that same first visit
Once that admin is confirmed, the extension reads your Azure DevOps states and board columns and seeds a starting workflow mapping for the project they have open. A non-admin who happens to be the first visitor does not trigger this — the seed always comes from the confirmed admin’s visit, so it reflects an admin’s project, not a bystander’s.
What needs your attention
- Review the seeded workflow mapping
Auto-discovery is a best-effort starting point, not a guarantee. Open Configuration → Workflow Mapping and confirm the states it picked match how your team actually works (see §8 below).
- Decide your access mode
By default every licensed user in your org can open the extension. If you want to control who gets in, switch to assigned-users-only access and start assigning people in Configuration → Access Control.
- Assign or approve the first few users
If you are not using assigned-users-only mode, nothing further is required — anyone in your licensed org can already open the extension. If you are, add people directly or watch for access requests (see §2).
2. Rolling out to your team
A sensible sequence for getting your team from install to value.
- 1. Admin opens the extension first
This claims the admin role and seeds the initial workflow mapping (§1). Do this before inviting the rest of the team.
- 2. Decide who gets in
Licensed-users mode (the default) opens the extension to your whole org. Assigned-users-only mode caps access to a seat count and requires assigning people by name or by ADO group (§5).
- 3. Point your team at the extension
Everyone else opens it from their Azure DevOps project. A user without access sees a one-click “request access” option that a licensed org exposes automatically.
- 4. Check for pending requests yourself
Access requests are not push-notified — no email, no badge, nothing outside the extension. An admin has to open Configuration → Access Control and look at the pending list. If nobody checks, requests just sit there.
- 5. Set organisation defaults once you have a rhythm
Once a few people have configured dashboards the way your team likes them, save those as organisation defaults so new joiners start from a sensible baseline (§6).
Access requests are not push-notified.
There is no email, badge, or alert when someone requests access. An admin has to open Configuration → Access Control and check the pending list. Build a habit of checking it, especially in the first few weeks of a rollout.
3. Access control
Access Control decides who can open the extension and what they see inside it. There are two roles.
Can manage access control, seats, organisation defaults, workflow mapping, and view the admin activity log. The first admin is claimed automatically (§1); anyone can be granted admin afterwards through Access Control.
Can use the analytics views they have been granted visibility into. Cannot change access control, seats, or organisation-wide settings.
Claim flow
The first Azure DevOps Project or Organization Administrator to open the extension is claimed as admin automatically (see §1). After that, anyone can be granted admin from Configuration → Access Control — an admin assigns the role to another user the same way they assign access.
Per-view visibility
Regular members see a default set of views out of the box. Admins can grant or remove visibility into individual views per user from Configuration → Access Control.
User Metrics member switch
The User Metrics view (per-person scores) is off for regular members by default. An admin has to turn it on deliberately in Configuration → Access Control — it is never granted automatically alongside other view permissions.
This is an operational control, not a security boundary: your Azure DevOps organisation storage can be written by any member of the organisation. Access Control decides what the extension’s interface shows people — it does not, and cannot, restrict what Azure DevOps itself lets a member of your organisation do.
4. Seats & licensing
- What counts as a seat
A seat is an assigned place on your plan. Your admin assigns people in Configuration → Access Control; every assigned user — admins included — holds one seat. Seats can be freed and reassigned at any time.
- Licensed-users mode
The default. Every licensed user in your Azure DevOps organisation can open the extension — there is no per-user assignment and no seat cap to manage.
- Assigned-users-only mode
Access is capped to your plan’s seat count. New assignments are refused once every seat is taken, until someone frees a seat or you upgrade. Someone without a seat still sees the Dashboard, with a one-click way to request one from an admin.
- Fail-open by design
While the extension is still resolving your license status, it renders normally rather than blocking access — a brief backend hiccup can never lock out a customer who is actually licensed. The one exception: an organisation that ended its previous session locked sees a neutral, empty hold (never the lock screen itself) until status is confirmed, so a genuinely locked org does not see the app flash into view first.
5. Group seat rules
In assigned-users-only mode, you can point a seat rule at an Azure DevOps group instead of assigning people one at a time. A few rules that keep this predictable:
- ADO groups only
A rule points at an Azure DevOps directory group (built-in ADO groups or Entra-backed groups both work through the same lookup).
- Direct members only — nested groups are not expanded
Only people who are direct members of the group you pick get a seat. If your group contains other groups, their members are not walked into and do not receive seats through that rule.
- A 500-member cap per group
A group whose direct membership exceeds 500 is refused outright rather than partially applied — the rule reports the group as too large instead of guessing which members to include.
- Sync runs when an admin opens the Hub — there is no scheduler
There is no background job reconciling group membership. A person added to (or removed from) a mapped group gets (or loses) their seat the next time an admin opens the extension, or when an admin clicks “Sync now.” It never runs on a timer and never runs for a non-admin session.
- Manual grants are not group-managed
Assigning someone by hand in Access Control is independent of group rules. If you manually reassign someone who was originally added by a group rule, that seat becomes a manual grant — the next sync will not touch it, even if they later leave the group.
6. Organisation defaults
Organisation defaults let you standardise settings across your team. Two distinct actions control how far that reaches.
Stores your chosen defaults as the organisation’s baseline. This does not change anything for anyone who already has their own settings — it only affects people who have not set a personal value yet, or who explicitly opt in to the organisation’s setup.
A separate, explicit action. It publishes a push that overwrites the ticked fields for people who already chose their own values — the next time each of them opens the Hub. It is not instant and it is not silent: every recipient whose settings changed sees an undo banner naming exactly which fields moved, with a one-click way to restore what they had.
Per-project overrides & locks
A lock applies to per-project overrides and to what a new person starting fresh in that project inherits — it stops a project from setting its own value for a locked field. It does not touch any existing user’s own personal settings; those only change when an admin explicitly pushes the field with “Apply to everyone,” or when the person opts in themselves.
There is no admin-side way to recall or cancel a push once it is sent. The only way a pushed value gets reverted is the recipient clicking “Keep mine” on their own undo banner — an admin cannot undo it for them.
7. Admin activity log
- What gets recorded
Admin configuration actions across eight surfaces: workflow mapping, access control, seats, report subscriptions, the privacy setting, organisation defaults, the one User Metrics action (an admin exporting everyone’s scores), and the Industry Benchmarks org-wide opt-in/opt-out. Each entry records who, what surface, what action, and when.
- 400-entry cap, oldest first
The log keeps the newest 400 entries. Once it fills, the oldest entries are dropped to make room for new ones — there is no separate archive.
- CSV export
The log can be exported to CSV directly from the Admin Activity view, newest entry first.
- Operational record, not a tamper-proof audit trail
The log lives entirely in your organisation’s own Azure DevOps storage — Baytek never receives a copy, a count, or even the fact that an entry was written. That also means there is no hash chain, signature, or other tamper-evidence: anyone who can write to your organisation’s Azure DevOps storage could in principle edit it. Treat it as a helpful operational history, not as courtroom-grade evidence.
8. Workflow mapping
- What auto-discovery does
On the confirmed admin’s first visit, the extension reads your Azure DevOps state names and board-column placement and maps them into the six canonical stages the analytics engine uses (New, Queued, In Progress, Test, Review, Complete/Done). It falls back to sensible defaults for your process template if it cannot confidently infer a mapping.
- When to verify it
Check Configuration → Workflow Mapping right after install, and again any time you change your Azure DevOps workflow — add, rename, or remove a state, or switch process templates. Auto-discovery only runs once per org; it does not re-run automatically when your process changes later.
- What breaks when it is wrong
Cycle time, lead time, flow efficiency, WIP, aging, cumulative flow, process behavior, the cycle-time heat map, and Monte Carlo forecasts are all computed from the mapping. A state left unmapped or placed in the wrong stage skews every one of those numbers, silently — the dashboards will still show a number, just the wrong one.
For the full setup walkthrough, recommended mappings per process template, and how to verify it worked, see the Workflow Mapping setup guide.
Need help?
Our support team is available Monday through Friday, 9 AM to 5 PM Pacific Time.