Working in an assigned sphere

Download the Operator guide as a PDF

This guide is the day-to-day: inviting people, reading what comes back, and making sense of it when something looks wrong. Setting the workspace up — the spheres and their fields, the team, the keys — is in the Administrator guide. If you are an administrator you do both; the split is about the work, not about who is allowed to read which manual.

Everything below starts on Dashboard, the screen you land on when you sign in.

Your spheres are the boundary

An administrator assigns you one sphere or several. That assignment is not a filter laid over a larger view — it is the view. The people you work with, the search box, the status and sphere filters, the export: all of it is bounded by the spheres you hold, and a sphere that isn’t yours leaves no trace of itself on the screen.

Assignments change without ceremony. Gain a sphere and its people are simply there; lose one and they are gone at once.

What you see

The owners in your spheres. Each row carries their name and corporate address, their sphere, how many contacts they hold, whether they have a token, when their details last changed, and their status — Understanding grant states sets out the four. Contacts is a count and stays a count: it tells a filled-in card from an empty one without showing you anything inside it. Beside the Owners heading, how many seats you are using.

The day-to-day actions. Add an owner, generate a shared invitation link, send and resend invitations one at a time or several at once, export the list exactly as your filters have it on screen, and archive somebody with the bin. Invitations covers the sending.

An activated person’s card. The paper plane at the end of a row becomes a chevron once somebody is activated, and the chevron opens their card. Reading a card covers what is behind it and what opening it records.

Whether somebody has linked a token. The token column says one thing and only one: this person has linked a token to themselves. Nobody else can do the linking, and a token that has not been linked appears nowhere in the Portal — there is no state in which you know a token exists but is unclaimed.

What your spheres ask for. Spheres in the navigation shows the emergency-field template of each sphere you are assigned to — the fields people in it are asked to fill in. The rules that govern a template, and the point at which it stops being editable, are in Spheres.

Your own account. Security, from the account menu: your second factor and how many recovery codes you have left. It is about your sign-in and nothing else.

What you don’t

Anything in a sphere you are not assigned to. Not in the list, not in search, not in the filters, not in the export, not in the seat count.

The inside of a card before the person grants access. Adding somebody creates a row with an empty card behind it. Until they fill in their own details and grant your company access, there is nothing to open — and there is no state of the product in which you see contacts nobody has agreed to share.

A card after the grant ends. A revoked row keeps its place in the list and its seat, and the card behind it closes. That is the owner ending something on purpose, not a fault.

Field values in the export. It carries who you hold and the state they are in: names, addresses, spheres, statuses, dates, whether there is a token. Never a single field value from anybody’s card.

Team. Adding managers, changing roles, resetting somebody’s password or second factor — administrators only, and the section is not in your navigation.

Settings, and the Integration API keys inside it. Administrators only, the same way.

A delete button. There isn’t one, anywhere in the Portal. The bin archives.