Reports
The portal's Reports section (/portal/reports) turns the activity you send into ready-made pages: one person's week, a timesheet, change control, AI usage and cost, compliance, Microsoft 365, the knowledge base, cloud changes, and a facet explorer over everything. Every page reads from the same activity, so a person, a client or a repository looks the same wherever it appears.
All report pages are Live. Any signed-in member of the tenant can open them; a few team-wide views are offered to tenant admins and auditors only (noted below).
Reports landing
/portal/reports shows:
- All activity: a daily heat strip of everything in the tenant for the chosen period, with User and Product filters.
- One card per report, each with a Live badge once its sources have sent activity and a count for the last 24 hours. Click Open report / Open pack to go in.
The report pages
| Report | URL | What it answers | Reads activity from |
|---|---|---|---|
| My week | /portal/reports/person |
What did this person do across every tool this period? | Every source, for one person |
| Timesheet | /portal/reports/time |
How many hours went to each client or project, per day? | Meetings, calls and work activity from every source |
| Change control | /portal/reports/devops |
What changed, was it approved, and when did it reach production? | Systems of kind vcs (Azure DevOps service hooks) |
| AI usage (page title Claude Code) | /portal/reports/ai-usage |
Who uses AI tools, how much, and what does it cost? | Systems of kind ai (Claude Code OpenTelemetry) |
| Compliance | /portal/reports/compliance |
What is shared outside the company, who outside opens files, and where do secrets or personal data turn up in AI prompts? | SharePoint / OneDrive systems, plus AI prompts |
| Microsoft 365 (page title O365 Activity) | /portal/reports/o365 |
Meetings, calls, mail, files and sign-ins across the team | Systems of kind teams, outlook, sharepoint, identity |
| Knowledge base | /portal/reports/kb |
What knowledge is edited and read, by whom; ticket flow | Systems of kind kb (Umbraco KB integration) |
| SIEM | /portal/reports/siem |
What changed in your Azure subscriptions, and which changes were high risk? | Systems of kind cloud (Azure Event Grid) |
| Activity | /portal/reports/activity |
Any slice of your activity, broken down by every facet you have | Every source |
How a page finds your systems
Report pages look up your systems by kind, not by name, so they work whatever you call your systems. A page shows its Connect message only when the tenant has no system of the kind it needs; otherwise it loads and shows no activity in this range when the period is empty.
The portal sets a system's kind from the last part of its name when you create it:
| Name ends in | Kind | Used by |
|---|---|---|
otel |
ai |
AI usage, My week (AI sessions) |
devops |
vcs |
Change control |
teams, outlook, sharepoint, entra |
teams, outlook, sharepoint, identity |
Microsoft 365, Compliance (SharePoint), Timesheet |
kb |
kb |
Knowledge base |
azure |
cloud |
SIEM |
host |
host |
(host changes, coming) |
| anything else | custom |
Activity, Messages, My week |
So acme-otel, claude-otel or plain otel all count as an AI source, while a system named claude-code is custom and the AI usage page will not find it. The API accepts an explicit kind when a system is created through POST /api/v1/tenants/{tenantId}/systems; the portal's Mint new system form does not ask for one.
Choosing the period
Every report page has period chips (last 7 days, last 30 days and so on, depending on the page) and a custom range. Pages also accept a fixed period in the URL, which is handy for sharing a link:
/portal/reports/devops?from=2026-09-28&to=2026-10-02
from and to are YYYY-MM-DD days in UTC, and to is inclusive. The older form ?preset=custom&from=<ISO time>&to=<ISO time> still works.
My week
/portal/reports/person shows the signed-in user's own week. To open someone else's, add their person id or email:
/portal/reports/person/{personId}
/portal/reports/person/jane@example.com
/portal/reports/person?email=jane@example.com
Panels: headline numbers, a timeline stacked by source, totals by source, time by project or partner, activity by project, meetings (with title and duration), AI sessions, and every activity in the period with CSV export.
AI sessions come from the tenant's ai systems and are counted by session.id. Activity that carries no session.id is grouped into one session per day, so it still counts.
Timesheet
/portal/reports/time builds a week grid for one person: rows are clients or projects (switch with Group rows by), columns are Monday to Sunday, and each cell shows total hours with the meeting / work split. CSV export gives Date, Person, Project|Partner, Hours, Meeting hours, Work hours.
How hours are worked out:
- Meetings use real attendance and call durations; a calendar invite counts only when no attendance or call overlaps it.
- Work is grouped into sessions: activity less than 15 minutes apart is one session, and each session counts at least 15 minutes. Outlook mail reads (
outlook.audit.mailitemsaccessed) and Entra sign-ins (entra.signin*,entraid.signin*) are left out, since mail clients and single sign-on generate them all day. Other Entra activity, such as role or group changes, counts as work. - Each block goes to the client or project its activity belongs to, otherwise Unassigned.
?email=jane@example.com opens that person's week; ?from=YYYY-MM-DD opens the week containing that day. Tenant admins and auditors also get a team summary (person × client totals) and a person picker.
Change control
/portal/reports/devops (the route is kept from the earlier DevOps pack). It needs an Azure DevOps service-hook system (see 71-integrations-azure-devops.md).
Panels:
- Headline numbers: pull requests merged, unapproved changes, deploys, production deploys, build-fail %, median PR cycle time, median lead time.
- Change timeline: pull requests, pushes, builds and deploys per day, with unapproved changes and direct pushes as their own series.
- Unapproved changes: every pull request merged with no approving vote, and every direct push to
main/master. - Deploys per environment, with succeeded / failed counts per environment.
- Build-fail rate by repository (top 10).
- Lead time: pull request opened → merged → first successful production deploy for the repository.
- Production deploys with no linked PR: a production deploy with no pull request merged earlier in the period for that repository.
- Top contributors and top repositories.
- Changes list with CSV export: the pull requests, production deploys and unapproved changes behind the panels. Pushes, builds and pull-request updates are counted in the charts, not listed.
Filters: period, User, Repository.
What counts as approved. When the API stores a pull-request merge it writes change.state: approved when any reviewer voted 5 or more (Azure DevOps "approved" is 10, "approved with suggestions" is 5), otherwise unapproved. A push to main or master is direct_push, unless the push is the merge commit Azure DevOps creates when it completes a pull request (its commit comment starts with Merged PR), which gets no state. See 50-ingest-native.md.
AI usage
/portal/reports/ai-usage (page title Claude Code). It needs an ai system receiving Claude Code OpenTelemetry (see 72-integrations-claude-code.md).
Panels: headline numbers (total cost, active users, sessions, tokens, error rate), session density, recent sessions (time, person, model, tokens, cost, duration, severity; click a row for its detail), cost per day, top users by cost (one row per person, largest first), tokens by type, top tools used, and an Insights preview (model vs tool, spend by person and model, session flow). /portal/reports/ai-usage/sessions/{sessionId} shows one session as a tool waterfall with its activity.
Costs show in US dollars ($40.87; four decimals only below one cent). Filters: period, User, Model.
Prompt text is never shown on this page.
Compliance
/portal/reports/compliance. Three parts:
- External sharing (SharePoint and OneDrive): shares by exposure (
anonymous,external,internal) per day, top external parties by domain, anonymous links created and used, and a table of external and anonymous shares. - Guest file access: files opened or changed by people from outside the company, by activity type, with a table.
- Sensitive content in AI prompts: findings by category (
secret:aws-key,secret:connection-string,pii:emailand so on) and by person, and how many prompts were scanned.
Filters: period, person email, partner (when your tenant has a partner facet).
Prompt text is never displayed. Findings show time, person, category, source and type. Opening one finding fetches that single activity only when you click it.
Exposure, the external party's domain and guest access come from fields the API adds when it stores the activity; sensitive-content categories come from the API's prompt scanner. See 50-ingest-native.md.
Microsoft 365
/portal/reports/o365 (page title O365 Activity). Headline numbers (active users, Teams meetings, calls, files touched, emails sent, Entra sign-ins), activity density coloured by service, Teams calls, most active SharePoint sites, Outlook sent / received, Entra sign-in success / failure, and recent activity with a detail drawer. A Service filter narrows the page to Teams meetings, chat, calls, Outlook, SharePoint, OneDrive or Entra sign-ins.
Each panel reads your own system of that kind; a service you have not connected shows its own empty state while the rest of the page loads. See 70-integrations-m365.md.
Knowledge base
/portal/reports/kb: edits, publishes, tickets opened / closed and comments; activity density coloured by content type; ticket state flow (from each ticket's status changes); top authors; sprint burndown; most-edited content; release and deployment tickets; recent activity; insights (state-flow diagram, calendar heatmap ending at the selected period, content-type breakdown). Filters: period, User, Product, Content type. See 73-integrations-umbraco.md.
SIEM
/portal/reports/siem: Azure control-plane changes from an Event Grid cloud system. Headline numbers (changes, high-risk changes, distinct actors, failures), changes over time, high-risk modifications (network security groups, role assignments, firewalls, key vaults), top actors, a subscription × day heatmap and top resource types. Filters: period, User, Product, Subscription, Resource type. Host-level change tracking is shown as coming.
Activity
/portal/reports/activity is the general explorer. Pick a period and, optionally, one facet and value (a person, a partner, a source, any facet in your catalog) to scope the page. You get a per-day activity chart and one breakdown panel per facet in your catalog, each listing its top values.
Activity with no value for a facet is left out of that facet's breakdown, and the panel says how much of the period it covers (for example 1,234 of 5,678 events (22%) have a Person value).
Facets behind the reports
Every number, chart and top list on Change control and Compliance is counted in the read index from facets, not by reading activity one by one; only the short tables (unapproved changes, lead time, production deploys, external shares, guest access) read individual activities, and those reads are capped. The pages check your facet catalog first and show an explanatory empty state for any facet that is missing.
| Facet | Read from the activity body | Used by |
|---|---|---|
change_kind |
change.kind |
Change control |
change_state |
change.state |
Change control |
repo |
repo |
Change control |
environment |
deploy.environment |
Change control |
target_branch |
pull_request.target_branch |
Change control |
build_result |
build.result |
Change control (build-fail rate) |
deploy_result |
deploy.result |
Change control (deploy succeeded / failed) |
exposure |
sharing.exposure |
Compliance |
shared_with_domain |
sharing.shared_with_domain |
Compliance |
link_type |
sharing.link_type |
Compliance |
shared_with_type |
sharing.shared_with_type |
Compliance |
actor_origin |
actor.origin |
Compliance (guest access) |
sensitive_content |
sensitive.category |
Compliance |
Tenant admins manage facets at Administration → Facets (/portal/admin/facets). Changes collect as a draft; Publish & reindex makes them live and re-projects the tenant's existing activity, so a new facet also covers older activity. Facet rules extract values by JSON path; regular-expression extraction rules are rejected (422) because the read index cannot run them.
These facets come from Fyin's standard facet set for change control and compliance. If a panel says a facet is missing, ask support to add the set to your tenant.
Querying the same data yourself
Every report is built on the public query API, so you can reproduce any number:
| Need | Endpoint |
|---|---|
| Counts by any facet, across sources | POST /api/v1/activity/search with groupBy (60-query-api.md) |
| Time per person per client / project | POST /api/v1/reports/time |
| Raw activity for one system | GET /api/v1/messages?system=… (60-query-api.md) |
The portal Messages page lists raw activity with the system name in the System column; /portal/messages?system=<name or id> opens it filtered to one system.
Not available yet
| Feature | Status |
|---|---|
| Alerts (email / chat) on a finding or threshold | Coming soon |
| Scheduled report exports | Coming soon |
| Custom dashboards (embedded Grafana) | Deferred |
| Report pages laid out for phone screens | Coming soon; use a desktop browser |
What's next
| Goal | Doc |
|---|---|
| Connect Azure DevOps for Change control | 71-integrations-azure-devops.md |
| Connect Claude Code for AI usage | 72-integrations-claude-code.md |
| Connect Microsoft 365 | 70-integrations-m365.md |
| Query the data yourself | 60-query-api.md |