Who on the team opened which account: the owner's log

You say «who signed in», and you are asking about three different things at once, each with a list of its own: the three tabs of the Logs section on the Members screen.

Piling them into one stream means paging through everything to find the one row. So you read the same rows through three separate lists.

1. 1

   Actions

   Who did what across the whole workspace, newest first, with the person's email instead of an internal id.

2. 2

   Profile sessions

   Only profile starts and stops: this is the answer to who was working when.

3. 3

   IP log

   Sign-ins and machine registrations. A sign-in carries an address and a country; the machine name comes with the registration row.

Every action you will later argue about leaves one row: who did it, in whose workspace, what exactly and when.

A small block of detail sits beside it. For a profile edit it shows what changed and to what.

An edit that changed nothing leaves no row at all. A «save» pressed without touching a field does not litter the log.

The Profile sessions tab answers that more directly than the others: only profile starts and stops remain in it.

In a row you see the person, the name the profile carried that day and the time. A profile renamed later therefore cannot confuse you after the fact.

A stop arrives as its own row, so a pair of rows shows both the start of the work and the end of it. No second row means the window is either still open or closed in an unfriendly way.

The third list gathers sign-ins and new machines, and it answers the question about somebody else's hands.

The address in the row is the real one, the address the request reached the server from. An address written into a header is set by anyone, and a theft would then be traced down a planted trail.

1. 1

   The address

   The one the request actually arrived from, not the one that announced itself.

2. 2

   The country

   A trusted intermediary in front of the server sets it, and nobody else does.

3. 3

   The machine

   The name it was registered under with you, and its system when there is no name.

A log with secrets inside becomes the handiest place to steal them from, so not every field carries a value.

Notes, tags, login, password and the one-time key give only the fact of an edit. A proxy goes in as an address with no login and no password.

A field the app does not have yet lands in the log as a bare fact too. The value of a new field cannot slip in by itself, even if a secret turns up inside it tomorrow.

Two live sessions of one account from two cities are exactly the picture that sends an account for review. Your machines cannot see each other, and agreeing by voice does not always work.

So a profile carries one lock for everyone: a second launch gets a refusal and sees who holds the profile now. A machine pulled out of the socket releases it by itself after three minutes.

While the window is open the app renews that lock every minute. A request that did not name its own machine will not take a busy profile.

The lock on a profile is held by the clock rather than by a promise. While the window is open the program renews it once a minute; a machine that went silent releases the profile after three minutes; a person who left the team releases everything they held that very second.

A request that does not name its machine does not get a busy profile. So every row in Profile sessions has a machine, and «who held the profile at that hour» is answered by one row.

Three rules work over those same rows, and each looks for a shape that usually comes before a lost account. What they find stands in the Needs your attention block on the Members screen.

They look a month back. A person's first sign-in does not land in that block: otherwise every new arrival would scare you on the day they arrive.

The three densest clusters are named and the rest are folded into a count. Thirty identical rows and you would stop reading at the fifth.

An account has gone for review, and you have one question: whose hands touched it last. The order below answers it in four steps and needs nothing but the log.

Each step narrows the circle, and by the fourth you are left with a name, a time and a machine.

1. 1

   Find the profile in Profile sessions

   That tab gives you a pair of rows: who opened the profile, when, and when they closed it.

2. 2

   Look at the edits of that day

   The Actions tab shows whether the proxy, the group or the fingerprint template changed on it.

3. 3

   Check that person's sign-in

   The IP log tab names the address, the country and the machine they came from that day.

4. 4

   Look into Needs your attention

   The three rules are already counted for you, and a sign-in from a new country stands first.

The log answers exactly as far as you prepared the question. Four people under one shared sign-in merge into a single nameless row.

The four preparations below are done once and pay for themselves on the first day of an argument.

1. 1

   A seat of their own

   The person signs in with their own email, and the row then names them rather than a sign-in shared by four.

2. 2

   Name the profile by the account

   That day's name stays in the row for good, and «Profile 7» will tell you nothing a month later.

3. 3

   A client in their own group

   Groups narrow what a person sees, and narrow your own question to one client at the same time.

4. 4

   One proxy per profile

   One address across four draws them into a cluster platforms take down whole.

A parting cuts access both ways at once: they stop seeing the workspace, and the workspace stops seeing their profiles. The lock they were holding is lifted by the same move.

Their rows stay with you all the same, and those are what you need right after a parting. A second invite to the same address does bring them back into the workspace.

The owner and an admin open the workspace history. A manager and an operator are refused at that door, and it is a refusal rather than an empty screen.

Reading it leaves no trace of its own. A proxy password taken out for a launch does leave a row, and you will see that one in the Actions tab.

A program key reads the log only when it is allowed to separately. You grant a key that right the same way you grant a person a role.

A key for programs gets its rights from one list of seven lines: read and edit profiles, launch the browser, read and edit proxies, read flows and read the log. The list is one for the whole server: it is checked when a key is issued, it stands at the entrance of a call, and it is shown in the dashboard.

A right that can be granted but not applied is not on that list. A key without the log right gets the same refusal at this door as an operator.