Appearance
The reference console, and what it is not
Five full-page captures of a competitor's console (Safetica) were supplied as a target for this product's screens, and they were the right thing to work from: a screenshot of a shipped product settles arguments about layout that prose cannot.
A capture is not a specification. It shows one vendor's current state, which includes the parts they have finished, the parts they describe as unfinished, and the parts we would refuse to build. Without that separation written down, a future pass reads a gap between our screen and theirs as a defect and closes it - including the gaps that are deliberate.
This note is for us. It is not a competitor comparison and it is not marketing: nothing here belongs in anything a customer sees.
Sources
| Source | What it covers |
|---|---|
| Five page captures supplied 2026-09-20 | Dashboard, Devices, Data classification, Policies, Behavior analysis |
| The vendor's behaviour-analysis upgrade limitations page | What their own documentation says is missing after their S10→S11 upgrade |
| The vendor's behaviour-analysis page | How their active-time measurement is defined |
The two page quotations below are recorded in DLP-334 and were not fetched from here - this host has no access to them. They are attributed, not verified, and anybody relying on one should read the page before quoting it onward.
What we matched
| In the capture | Ours | Ticket |
|---|---|---|
| Rail, topbar, page head, card anatomy, table chrome | Matched, at the reference's measured type scale | DLP-310 |
| Devices list: filter bar, tabs, status pill groups with overflow, column glyphs, pager | Matched | DLP-310 |
| Data classification list: toggle, stacked name and description, last-update column | Superseded by the first-class classification → OR rules → AND elements workspace; the reference treated one detector as one classification | DLP-402 |
| Policies list, column for column | Matched | DLP-316, DLP-317, DLP-318, DLP-319 |
| Behaviour analysis: band, tiles, per-person table, drill-through | Matched in shape, in operations | DLP-321, DLP-323 |
| Behaviour analysis in time: total active time bar, per-person total and daily time, shares, time per grouping; period, scope and add-filter chips, saved views, column picker, export | Built in the console, shown only where a tenant measures active time; scope is by agent group, never by person | DLP-1244, ADR-0043 |
What we refused
Time per person - refused until 2026-09-28, then decided. Their behaviour screen is built on it: total active time, daily active time, and minutes per person under Gaming, Social media, Job search and AI tools usage. Their own documentation defines that measurement as clicks, typing and mouse movement in the active window, stopping after five minutes of inactivity and reported in man-days of eight hours.
DLP-320 refused it, and the paragraph here said the refusal was not a gap to be closed later: closing it meant building the telemetry, adding a row to the privacy register, and somebody with the authority signing the commitment. On 2026-09-28 the owner signed it. ADR-0043 decides the narrow form - hourly totals by application and host, off until an Owner turns it on, no titles, keystrokes or screen contents - and PRIVACY_MODEL.md records it.
The console half is built (DLP-1244): where a tenant measures active time, the behaviour screen shows the reference's time figures, says it is showing time, and keeps every figure about a named person behind the same switch, reason and audit entry as before. No endpoint measures it yet: the Windows sampler is DLP-1245 and the browser host DLP-1246, so until they ship a tenant that turns it on sees zero, with that reason, rather than a figure.
What we still do not do: report in man-days. The time columns follow the tenant's groupings, as the operation columns do (see below).
Naming individuals by default. The capture lists employees by name in the first column. Ours is gated twice - per_user_enabled per tenant, and the behaviour:read permission, which Owner and Admin hold and Security Analyst does not.
Columns and views named for protected activity. Job search is a column in the capture. This paragraph used to say the product refuses to ship such a grouping; DLP-322 then seeded four groupings, Job search among them, as rows a tenant edits or deletes like any other, and PRIVACY_MODEL.md §9 says so. What is still refused is a shipped view for it: one click from a menu to a list of the people who might be leaving (DLP-327). A column appears only when the window has activity in that grouping (DLP-332).
What the vendor calls unfinished
Their own upgrade-limitations page says, as recorded in DLP-334:
- "Several customizable charts and interactive statistics lists are not yet implemented." So the charts in those captures are the ones that exist, not the ones they intend. Matching them exactly is matching a waypoint.
- "Records in Behavior analysis can't be grouped at all." Grouping is listed as coming. Our band drill-through (
DLP-323) is a grouping, so on that point we are ahead of the capture rather than behind it. - Their previous version's Remote work report "will not be available", with no return date. Not something to reproduce.
What we have not done, and know it
Screens in the captures with no equivalent here: App usage, Website visits, Email traffic, Cloud services. The first three need telemetry this product does not collect, and the first two are refused outright by PRIVACY_MODEL.md §3. So their absence is a decision for the first two and unbuilt capability for the third. Cloud services is partly answered by SharePoint discovery (DLP-1194), whose findings are under Discovery rather than on a screen of their own.
What we have deferred, with the reason
The export stays CSV; .xlsx waits for somebody to ask (DLP-333). The reference exports the filtered behaviour table as .xlsx. Ours writes CSV in the browser from the rows already on screen - no new endpoint, no second path to the same identities, and nothing in the file that is not on the screen somebody justified looking at.
An .xlsx is a zip of XML, so writing one is not hard; the cost is not the code. It is a new dependency in a product that clears every dependency for licence and supply chain, carried permanently, to produce a file that the thing an analyst actually does with it - open it in a spreadsheet - already reads. That trade is worth making when a customer names the format and says why, and not before. Recorded here so the next person does not add a library to match a screenshot.
The format is stated where somebody meets it: the export control on the behaviour screen says it downloads the rows on screen as CSV.
The device inventory exports as CSV too (DLP-365). The reference exports its devices table to .xlsx in one click. Ours writes CSV in the browser from the columns on screen, so the file and the table cannot name different columns - the server does not know which columns are shown, and a second list of them there is one that drifts.
The .xlsx reasoning from DLP-333 applies unchanged and is not repeated per screen: a permanent dependency cleared for licence and supply chain, to produce a file the spreadsheet already opens. If a customer names the format and says why, one library serves both exports.
Two things ours does that theirs does not describe: the file carries every status chip rather than the three the table had room for, and when the export stops at its five-thousand-row cap the file says so in its own last line. A CSV is read somewhere else, later, by somebody who did not click the button.
The dashboard's layout is fixed, and that is a decision (DLP-341). The reference's FAQ says its widgets and layout are "not customizable for now" - a limitation they intend to remove. Ours is fixed for a reason we would keep: a dashboard that differs per viewer makes "the dashboard said X" unverifiable afterwards, which matters on the one screen most likely to be quoted in an incident review or shown to an auditor. Two people looking at the same tenant on the same morning should see the same page.
The one difference is by role and is said on the page (DLP-542): a Viewer gets the same layout and every same figure, and where the rankings of named people and endpoints stand they read not named for your role. That keeps the sentence above true of every number, which is the part a review quotes; what it withholds is who, and it withholds it visibly.
The cost is real and is accepted: an operator who never looks at one panel cannot remove it. If that becomes a complaint it is worth answering with per-tenant configuration, which every viewer shares and which can be recorded, rather than with per-user layout that nobody can reconstruct. Filed against nothing today, because nobody has asked.
Recorded so the next pass does not read the reference's own roadmap item as a requirement and build per-user dashboards to match a screenshot.
How to use this note
Before treating a difference from a capture as a defect, check it here. If it is not listed, it is worth deciding deliberately and adding a row, because the next person will ask the same question.