Custom Reports¶

Experimental

Custom reports are off until an operator switches them on under Admin → Experimental. The "describe it in plain language" half also needs the optional report generator container. Everything else works without it.

The Reports tab lists the reports this deployment offers. Next to the ones that ship with Identity Atlas, you can build your own: pick what to report on, add conditions, choose columns, and save it. A saved report behaves exactly like a built-in one — it opens in its own tab, runs against the latest data every time, and can be downloaded.

You need the Build custom reports permission (data.write.reports). Everyone who can read data can open, run and download the result.

Building a report¶

Reports → New report opens the report builder in its own tab.

Name it. The name is what colleagues see in the list, so make it the question it answers — "Guests without an active manager" rather than "report 3".
Choose what to report on: Users, Groups, Accounts (including service principals, managed identities and AI agents), Resources (roles, applications, permissions, business roles, Azure resources), Persons (identities, with their linked accounts) or Contexts (groupings such as departments, tags or the applications of an application catalogue — pick the kind with a Context type is … condition). Contexts are built here in the editor; the Ask box does not produce them yet. For a context that groups resources you can also show and filter on how much access it carries — Resource count, Assignments (direct and via a role), Holders — as counted after the last sync.
Add conditions.
- + condition — a field of the thing itself: Enabled is No, Name contains LIC, Created is more than 90 days ago, Group count is more than 30.
- + related condition… — something about what it is connected to: has no Manager, has Manager where Enabled is No, is a member of a group where Name contains LIC, has no Owners.
- + any/all group — for an either/or: any of: has no owner · has an owner where Enabled is No.
- + compare with… — see Comparing with another group or person below.
Pick columns. Click a column name to add or remove it. Besides the fields themselves you can show things like the manager's name, the groups someone is in, the business roles they hold, or a count of any of those.
Or count instead of list. Count per turns the report into one row per distinct value, with the number of records that have it — how many users per department, which job titles exist and how many people hold each. Conditions still apply; columns do not, because a counted report has two columns of its own: the value and the count. Records with no value at all get their own row, so the counts add up. Biggest group first, unless you count per a date — that is not offered, because it would put nearly every record in a group of its own.

Your own attributes¶

Besides the fields every installation has, the builder offers the attributes your own crawlers stamp on the data: sfDepartmentID, employeeType, extensionAttribute5, an OU path. They are grouped under From your data in the field and Count per menus, and behind Attributes from your data in the column picker. They work like any other field — filter on them, show them, count per them — and they are the same attributes you can filter a Users or Groups list on.

Entra directory extensions are shown by their readable name (sfDepartmentID), not the long extension_<id>_sfDepartmentID they arrive under. What a saved report stores is the underlying key, so renaming a display name never makes a report point somewhere else.

Users and accounts have three sign-in fields, read from the same data as the standard Never signed in and Stale accounts reports, so they give the same answers:

Last sign-in — the most recent sign-in, interactive or not.
Days since last sign-in — counted back from when that system's sign-in data was last collected, not from today. If a crawl stops running, accounts do not all quietly turn stale. Use Days since last sign-in is more than 90 for "not signed in for 90 days".
Sign-in data collected — when that account's system last collected sign-in activity. It is empty for systems that collect none.

For "never signed in", use Last sign-in is empty and Sign-in data collected is not empty. Without the second condition, every account of a system that collects no sign-in data would be listed too. 5. Preview. The builder shows what will run in plain language, the number of rows, and the rows themselves. Read the plain-language version before you trust the result — that sentence is generated from the definition that actually runs. 6. Save. The report appears for everyone under Custom reports on the Reports tab, with your name as its author.

Rows are clickable: a row about an account opens that account's detail tab.

Describing it in plain language¶

When the report generator is deployed, the builder has a Describe it box. Type what you want:

Guest accounts that don't have a manager, or whose manager is disabled

The model turns that into a report definition. It never sees your data — only your question, the list of fields it may use, and, for a name you mention, which of those fields the name occurs in (see Names in your question). What comes back is always shown as editable criteria plus the plain-language reading, because the model is often right but never guaranteed to be right. Check it before you save.

The generator may answer with a question instead of a report:

"Did you mean…?" — you named something (a business role, a group, a person) whose name does not match exactly. Pick the right one, type the exact name, or keep what you wrote. This one is reliable: the database does the lookup, not the model.
"Which should the report match?" — you mentioned a name (an organisation, a code) that the report it built does not use. You get the fields that name actually occurs in — for example Company contains "Contoso" or Email contains "Contoso" — or you can leave it out. When the model had filtered on a system instead, picking a field also removes that system filter. Nothing runs on the guess.
"I cannot build this" — the report needs information Identity Atlas does not hold, and you get a note saying so rather than a report built on the wrong field. Asking for users with MFA switched off is an example.
A clarifying question — it can ask when a request could mean two different reports, and you can answer or tell it to use its best guess. Do not count on it. In testing it guessed on both deliberately ambiguous requests instead of asking — "everyone with admin rights" came back as one kind of admin without saying so. Be specific, and read the plain-language summary: that is where a guess shows.

Names in your question¶

Names are recognised when they are clearly names: text in quotes, codes in capitals (ACME, SAP), and capitalised words that do not start a sentence (Contoso, Northwind Health+). Before the model answers, Identity Atlas looks each one up as a whole word and tells the model where it is — so "guests from Contoso" filters on the company rather than on something the model guessed. A lower-case name ("guests from contoso") is not recognised this way: put it in quotes, or capitalise it, when the model gets it wrong. Two-letter words are never looked up — they occur almost everywhere.

Attribute names work the same way. Name one of your own attributes in the question — "how many users per sfDepartmentID" — and Identity Atlas looks it up before the model answers and tells it the exact field to use. An attribute the question does not name is not offered to the model at all, which is why an unrecognised name comes back as "I cannot build this" rather than as a report on the wrong field.

You can keep talking to it: "only enabled accounts, and show the department" updates the definition you have, including any changes you made by hand.

The first question after an update, or after the model has been idle, takes longer — the builder says so while it warms up.

Comparing¶

Role-mining questions compare two sets of members rather than filtering rows. + compare with… reads as a sentence:

has exactly the same Members as resource "Fortigi - Algemeen - Maten"

exactly the same — identical membership.
contains all of — has everything the other one has, and possibly more.
only items also in — has nothing the other one does not have.
mostly the same (≥ %) — overlaps by at least the percentage you set.

You can compare members of groups, the groups someone is in, the business roles they hold, what an account has access to, owners, and the accounts of a person.

A comparison adds three columns automatically: Similarity %, what is only here, and what is missing compared with the reference. Results are sorted by similarity, so the closest matches are at the top.

Combine it with an ordinary condition to get the question a role-mining analyst actually asks:

Groups that have the same members as business role "Fortigi - Algemeen - Maten", but which are not part of that business role

What it cannot do¶

No free-form SQL. Everything is built from the fields and relations Identity Atlas knows about, which is also why a report can never change or delete data.
One count per report. Count per counts records per value of one field. It cannot count per two fields at once, add up anything other than records, or be combined with a comparison.
No history or trends — a report always reflects the data as it is now.
No comparing two fields of the same record (for example: people whose department differs from their manager's).
One step at a time in a relation: "groups whose owner is disabled" works; "groups whose owner's manager is disabled" does not.
Only data Identity Atlas holds. If a crawler does not collect it, no report can show it.
No chosen sort order. Neither the editor nor the plain-language box offers "biggest first" or "newest first", and the report tab does not sort — download the result and sort it there. Comparisons are the exception: they always come back closest match first.
At most 1,000 rows by default (5,000 at most). A report that reaches its cap says so above the results — the rows shown and the download are then only the first ones. Add a condition to narrow it.

Edit a custom report from the list, or from the report tab itself. The definition, name and description can all change; the report keeps its link.
Delete removes it for everyone.
Custom reports are shared across the deployment: everyone sees the same list, and the list shows who created and last changed each one. They are not personal drafts.
A report remembers the record it compares against, not just the name, so renaming a business role does not break a saved comparison.