Read your directory before you invite

Before you start

You need a connected directory, a read grant scoped to membership records, and a reason for reading it. The reason matters, because it decides how narrow the grant should be.

Register the read the same way as any other resource: plan it, apply it, read it back. A directory read is configuration, so a work key cannot make it.

Read membership records, not content

A directory read returns who exists in your organization. That is names, work addresses, teams, titles and status.

It does not read messages, files, calendars or documents. Do not request a grant that would, and refuse one that is offered.

Keep the scope to the part of the directory you need. Reading a whole company to invite one team is a grant you will have to justify later.

Treat the read as a point in time

Every response carries an observed_at time and a valid_until time. A directory is a live system, so your copy starts aging the moment you take it.

Once valid_until has passed, read again. Do not invite people from a list you took last month, and do not cache one into a spreadsheet that nobody re-checks.

If the read refuses, it names a safe reason and a next action. A missing scope is a grant to request, not a service fault.

Deduplicate on a stable identity

One person often appears more than once. They changed address, they hold a contractor record, or an alias survived a migration.

Match on the directory's stable identifier for that person. It is the one field designed not to change when a name or an address does.

Never deduplicate on a display name. Two people share a name more often than you expect, and merging them creates one grant covering two humans.

Never deduplicate on the address alone either. An address can be reassigned to somebody new, which is worse: the grant follows the address rather than the person.

Treat a job title as evidence only

A title tells you what somebody does elsewhere. It never grants anything in Compute.

Use it to decide who to ask about, and who to propose for which role. Then make the grant explicitly, have it approved, and read it back.

Nothing in Compute reads a title and widens access from it. A mapping that would grant privileged authority implicitly is refused, with a reason and a next action.

Keep only what you need

Take the stable identifier and the work address for the people you will actually invite. Leave the rest where it is.

Every field you copy is a field you now hold, protect and eventually delete. The directory is a better home for it than your notes.

Confirm success

The read reads back as VERIFIED and returns a current valid_until. Your candidate list has one row per person, with no duplicate identifiers.

Spot-check two rows against the directory itself. If a title or a status disagrees, your copy is already stale.

What to do next

Invite the people you selected, with the grant you chose, approved as one set. See how to invite your team for that step.

If membership changes often, stop doing this by hand.

Sync members from your directory or HRIS