Administration

Give people the access their work actually needs

Team administration controls who can see and do what. Invite people with the role they need, give them access to the right workspaces and projects, and review access whenever responsibilities change. This guide covers invitations, roles, client access and ownership.

Start with the workspace boundary before deciding which colleagues or clients should have access.

Two access boundaries

Organization membership and workspace or project assignment answer different questions.

Capability-led control

Viewing the roster, managing members, and assigning work remain separate permissions.

Verifiable handoff

An invitation becomes useful access only after acceptance and a check of the resulting view.

Organization membership and workspace access are different boundaries

An organization is the account boundary for members, billing, workspaces, and organization settings. A workspace is the working boundary for projects and product data. Joining an organization does not by itself promise access to every workspace or project inside it.

Always check the active organization and workspace before changing a role or diagnosing missing data. A person can have a valid organization role and still see only the workspaces or projects assigned to them.

The page separates viewing members from managing them

Opening the members page requires the organization member-view capability. Inviting people, seeing pending invitations, changing roles, and removing members require the member-management capability. Someone with read access can therefore inspect the roster without receiving team administration controls.

The labels below describe the normal intent of each role. Effective access is still decided by the current capability configuration and any authorized overrides, so a role label is not a complete permission report.

Role	Normal responsibility
Owner	Full organization control, including billing, deletion, and ownership transfer.
Admin	Manage members, settings, workspaces, and billing.
Manager	Coordinate people and assign access to workspaces and projects.
Editor	Create and edit work in assigned workspaces.
Viewer	Read assigned workspace data without editing it.
Client	Use a deliberately limited view of assigned projects.

An invitation is tied to one email address and expires after seven days

Choose the role the person needs now. Owner is not an assignable invitation role.

Enter the email address they will use to sign in.

Send the invitation and, when the interface returns a token, copy the invitation link if you need to share it directly.

Ask the recipient to accept while signed in with the invited email address and before the seven-day expiry.

Check the pending list rather than sending several invitations for the same access request.

Pending invitations remain manageable

Team managers can review the invited email, proposed role, creation date, and pending state. A returned invitation link can be copied again, and an invitation that should no longer grant access can be revoked.

A pending invitation is not membership. Confirm that the person appears in the member table after acceptance before assigning work or relying on their access.

Assign the work boundary after the organization role

Confirm which workspace contains the client's or team's data.
Use workspace and project assignments when the access mode or role calls for them.
Treat Client as an isolated, limited branch rather than a low rung that automatically inherits internal access.
Test the resulting view with the intended organization, workspace, and project scope.

When membership is correct but visibility differs, check the workspace access settings as well.

Role changes and removals take effect through the server

Editing a role or removing a member is a real access change, not a display-only preference. Check active assignments and ownership responsibilities first. The last owner cannot be removed; ownership must be transferred before that person can leave.

Non-owners can leave an organization from the member page. Owners must first leave another valid owner in place so the organization cannot become ownerless.

Crawl Foundry membership is the access record to verify

Crawl Foundry stores the organization membership used by product authorization. Synchronization to the external identity provider is best effort and can be repaired separately. If two systems look different, verify the current Crawl Foundry member record and capability result before assuming that a provider label controls product access.

Review access when responsibility changes

List current members and pending invitations.

Revoke invitations that are no longer expected to be accepted.

Compare each role with the person's current responsibility.

Check workspace and project assignments for viewers and clients in particular.

Keep at least one confirmed owner and a clear billing owner.

Record the change and verify the affected person's actual view.

Example: Giving a client read access

An agency invites a client contact with the Client role and assigns only the workspace for that client's brand. The contact can review reports without seeing other clients.

When the project ends, the agency removes the membership and revokes a pending invitation for a second contact who never signed up.

Frequently asked questions

How long is an invitation valid?

Seven days. It is tied to one email address and can be copied again or revoked while it is pending.

Does joining an organization give access to every workspace?

No. The organization role and workspace or project assignments work together. Assign the workspace that holds the person's data.

Can I remove the last owner?

No. Transfer ownership first. Owner is also not a role you can assign through an invitation.