Entra: a sign-in id is one record

The id is the record

A sign-in row has an id that identifies that record. A second row with a different id is a different record, even when the account, the application, and the day are the same. The account ties them to one directory object. It does not make them one authentication.

Quote the id whenever you quote a time or an IP from the row. A note that says “riley at 16:40 from Dublin” without the id cannot be found again if another row shares the minute.

Do not average two records

Two ids can have two addresses and two results. Write them as two lines. Do not average the times, pick the more familiar IP and drop the other, or describe them as one trip. If you need a sequence, list the ids in time order and keep every field attached to its id.

A field that groups related rows, when the export has one, is a grouping key. It is not a reason to delete ids. If you use it, still list the ids it grouped.

What to file

File the id, the time, the account, the application if you are discussing it, the IP, and the result. Repeat the block for each id. Do not file a sentence that has an IP and no id. Do not replace the id with the account name.

Worked case: two addresses, one account

The lab export has id a1 at 16:40:22Z from 203.0.113.10, result success, and id b2 at 16:41:05Z from 198.51.100.9, result failure. Both are riley@hackblue-lab.org and the same application. A draft says riley signed in once from the office and ignores b2 because it failed.

The note has two blocks, a1 and b2, with their times, addresses, and results. The failure is not dropped. The success is not described as the only event. Nothing in the note calls the pair one sign-in.

id: a1  2026-11-03T16:40:22Z  203.0.113.10  success  riley@hackblue-lab.org
id: b2  2026-11-03T16:41:05Z  198.51.100.9  failure  riley@hackblue-lab.org
write: two records
not: one sign-in, and not a dropped failure