Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.quiverstone.io/llms.txt

Use this file to discover all available pages before exploring further.

A user in Quiverstone is any individual with a login to your workspace. Users don’t exist in isolation — they get their access by being added to a Team, and (on Pro and Enterprise) to one or more Groups. This page covers how to invite users, how membership status works, and how to remove someone cleanly when they leave.
Users are always scoped to a single subscription. There is no concept of a user being “shared” across multiple Quiverstone workspaces — each workspace has its own user list and its own invites.

​
How users get access

Quiverstone uses a layered model. A user’s effective access is the union of what each of these grants:
  1. Team membership. Adding a user to a team determines what kind of access they have — ACCESS (consumer) or SETTINGS (admin) — and their role within that team (OWNER, ADMIN, MEMBER).
  2. Group membership (Pro/Enterprise only). Adding a user (or one of their teams) to a Group determines which Organizations, Accounts, and Customers they see, and which AWS Roles they can assume.
  3. Tier-driven capabilities. The subscription tier gates which team types and team roles are available at all.
If you want a user to see a specific Account, the question is almost always: “Which Group should reference them?” not “Which permission should I toggle on the user?”

​
Membership status

Every team membership in Quiverstone has a status field. Understanding it helps when troubleshooting missing access.
StatusMeaning
PENDINGThe user has been invited but has not yet accepted. They appear in the team list but have no access. Backfill has not run.
ACTIVEThe user has accepted the invite and signed in. Full team and Group access is in effect.
REVOKEDThe user was removed from the team. Any access granted through that team (including via Groups that referenced the team) is gone.
Backfill of existing resources only runs when a user’s status transitions from PENDING to ACTIVE. If you add a user to a new Group before they accept their invite, they will see the Group’s resources the moment they activate.

​
Inviting a user

The invite flow is the same regardless of team type, but who can send invites varies by tier.
1

Decide which team they should join

Pick the team that matches how they’ll use the workspace. Admins go into a SETTINGS team (Pro/Enterprise); consumers go into an ACCESS team.If you don’t have a suitable team yet, create one first.
2

Open the team and click Invite Member

Navigate to Teams, click into the target team, and click Invite Member.
3

Enter the invitee's email

The invitee does not need an existing Quiverstone account. The invite flow creates one when they accept.
4

Pre-stage their Group access (Pro/Enterprise ACCESS teams)

If you’re inviting someone to an ACCESS team on Pro or Enterprise, add their team to any Groups they should have access to now, so that backfill happens automatically when they activate.
This step is not needed for Consultant tier (everything is shared automatically) or for SETTINGS team invites (automatic co-ownership handles it).
5

Wait for them to accept

The user receives an email invite, accepts, and signs in. Their status flips from PENDING to ACTIVE and backfill runs according to the rules in the Teams page.

​
Who can invite users

TierWho can invite
FreeNo one (single-user tier)
ConsultantThe team OWNER only
Pro / EnterpriseAny SETTINGS team member, and any team OWNER/ADMIN within their own team
See the Capability reference for the full matrix.

​
Removing a user

Removing a user is done from the team page. Pick the team the user belongs to and use the Remove action on their row. What happens on removal:
  • Team grants (including automatic co-ownership on SETTINGS teams) are revoked immediately.
  • Any Group access the user inherited via that team is revoked — unless another Group or team still grants the same access.
  • Records the user personally owned on Free tier or created as the Consultant OWNER are not deleted. They remain on the subscription under the subscription owner’s control.
  • CloudTrail records of past role assumptions are preserved — removal is not retroactive.
If a user is in multiple teams, removing them from one team does not remove them from the others. To fully revoke someone’s access, remove them from every team they belong to.

​
Common scenarios

“A new hire needs the same access as the rest of the Ops team.” Add them to the Ops ACCESS team. Any Groups that reference the team will automatically include them when their status becomes ACTIVE. “I invited someone yesterday but they can’t see anything.” Check their membership status. If it’s still PENDING, they haven’t accepted the invite yet. If it’s ACTIVE but they still can’t see resources, confirm (on Pro/Enterprise) that they’re in a Group that references the resources — ACCESS team members see nothing by default. “A contractor finished their engagement.” Remove them from the contractor team they were in. Access disappears immediately. If the team was only created for that engagement, delete the team too — and delete any Groups that existed solely to reference that team. “Someone is leaving the company but I want to preserve what they built.” On Pro/Enterprise, records in a SETTINGS team are already co-owned by everyone else on the team, so removing the leaver does not lose any records. On Consultant or Free, there is only one owner, so you may need to have them transfer ownership of the subscription before removing their account.