Binding a Google identity to a person, end to end
A person record is bound to one Google account by that account's permanent subject identifier, written on the first sign-in that presents a non-empty one. A row created before any subject existed is adopted at that moment rather than duplicated. After binding, an address presented with a different subject is refused rather than quietly re-pointed at a new account.
The flow#
- Trigger — somebody signs in with Google for the first time, or for the first time since subjects were recorded.
- User or external event — Google returns an assertion carrying a subject identifier that is permanent for that account.
- Authentication and workspace resolution — the assertion is verified before anything is matched. An unverified assertion never reaches this flow.
- Ingest — two facts are taken from it: the subject, and the address the account presents.
- Canonical record — the subject is looked for. Found: this is a known person. Not found: a person row with no subject yet may be adopted, or a new one created.
- Reasoning — none, and deliberately so. Identity is matched on an exact permanent value, never inferred from a similar name or a nearby address.
- Knowledge, memory and rules — untouched. Binding an identity does not tell Connect anything about the business.
- Autonomy and approval — not involved, though everything a person later approves is attributed through this binding.
- Action through a provider — none beyond the verification already done with Google.
- Result — either a binding is written once, or an existing binding is confirmed, or a mismatch is refused.
- Relationship, timeline and memory — unaffected. A workspace's people are its customers and contacts; this is about who may sign in.
- Audit, usage and Needs You — a first binding and a refused mismatch are both worth recording, and both are.
Why the first non-empty subject, and not simply the first#
A person row can exist before any Google account has been attached to it: somebody was invited, or the row predates subjects being recorded at all. In both cases the subject field is empty. That empty value is the whole problem and the whole solution.
Treated as an ordinary value, empty matches empty — so the first person to sign in would match every unbound row at once, and the binding would attach to whichever happened to be found first. Treated as a sentinel meaning *not yet bound*, it matches nothing, and the rule becomes exact: a binding is written only from a non-empty subject, and only onto a row that does not already have one.
The row that predates the binding#
Adopting an existing unbound row rather than creating a new one is what keeps a person's history intact across the change. If a fresh row were created instead, the workspace would hold two records for one colleague: one with the permissions and the approvals, and one that can actually sign in. The symptom would be somebody signing in successfully and finding none of their own work.
| State of the row | What the sign-in does | Result |
|---|---|---|
| No row for this address | Creates one and binds the subject | A new person, bound from the first moment |
| A row with no subject | Adopts it and writes the subject once | History, permissions and approvals stay with the person |
| A row with this subject | Recognises it | Ordinary sign-in |
| A row with a different subject | Refuses | Nothing is written and no binding moves |
What the mismatch refusal protects#
An email address is reassignable and a subject is not, so the two can disagree. The interesting case is not hypothetical: a colleague leaves, their address is given to a new starter, and that new starter signs in. If the address were the key, they would arrive inside somebody else's identity — their permissions, their approvals, their attributed decisions.
Refusing that is the correct outcome even though it is inconvenient, because the alternative silently transfers accountability from one human being to another. The new starter is added as themselves, which takes a minute; unpicking a merged identity afterwards does not.
What can go wrong#
- Signed in, but nothing to see
- The binding worked and the person is not a member of any workspace yet. An invitation, not an identity problem.
- Signed in as the wrong self
- A browser offered a different Google account than expected. The binding is correct; the account chosen was not.
- Refused after an address change
- The address moved to a different Google account. The person is still bound to the original account, which is the record that has their history.
- Two rows for one colleague
- A row was created rather than adopted somewhere along the line. This needs merging by an administrator rather than a second sign-in attempt.
Questions#
Why not just use the email address as the identity?
Because addresses are reassigned and subjects are not. Using the address means that whoever holds an address today inherits whoever held it before, including their permissions and their name against past decisions.
Can a binding be moved to a different Google account?
Not by signing in — that path refuses, which is the protection. Moving a person to a new account is an administrative change made deliberately, so that somebody is accountable for the decision rather than it happening as a side effect.
What happens if somebody has two Google accounts?
They are two identities. Each binds to its own person record, and a workspace can admit either or both. Connect does not merge them on a matching name, because matching on a resemblance is exactly the inference this flow refuses to make.