Manage access with groups

A group is a named set of people in your organization. Grant the group a role on a resource once, and everyone in it gets that access. Add someone to the group later and they pick it up automatically.

Groups are available on organization accounts. A personal account has a single member, so there is nobody to share with and no access panel appears.

Roles you can grant

A group receives a role on one deployment, blueprint, or knowledge store at a time. There are three, and each adds to the one before it:

• Viewer reads the resource, including logs and traces. Secret values stay hidden.
• Editor also changes and operates it: redeploy, restart, stop, resume, trigger ingestion.
• Admin also grants and revokes access to it, and deletes it.

Access control covers the full model: the permissions behind each role, how account roles fit in, and what a denial looks like.

Create a group

Groups live in your organization settings.

The group list shows the first few members of each group as avatars. A 3+ marker means the group has more members than the preview shows. Open the group to see the full list.

Maintainers

A group has two roles, member and maintainer.

A maintainer cannot change what the group has access to, or archive or delete the group. Changing a group’s access takes Admin on the resource itself; archiving and deleting stay with account administrators.

A group can have as many maintainers as you like, and a maintainer can appoint others, so a team keeps running itself when someone hands it over or leaves. Anyone a maintainer adds to the group receives everything the group has access to, so appoint one deliberately.

A maintainer is always a member. Removing someone from the group also removes their maintainer role.

The Everyone group is the exception to all of this. It comes with your account, its membership is every member of the account, and nobody manages it, so it takes no maintainers and cannot be renamed, archived, or deleted.

Give a group access to a resource

Access lives with the resource’s other settings, so where you find it depends on the resource:

• Blueprint: open the blueprint, then the Settings tab.
• Knowledge store: open the store, then the Settings tab.
• Deployment: open the agent, then Configuration > Access.
• Audience: open the audience and select Access in its header.

The control is visible to anyone viewing the resource, but stays unavailable until the server confirms you can manage access. On a Settings tab or the Access subpage, the section explains why; an audience’s header button stays disabled and explains why on hover. Managing access requires Admin on the resource, or the account administrator role.

A public blueprint has no access section, because everyone can already find it.

Search for the group by name and pick a role. Unassigned groups are also listed below the search field, so you can grant access without typing. The change applies immediately.

A group stays one row under Who has access. Astropods does not expand it into its individual members, so the row you see is the grant you made. People who reach the resource through the account administrator role appear as a separate locked row, because that access comes from the account and cannot be revoked here.

Manage a group’s access from the group

The group page has a Direct Access section listing every resource the group reaches and at which role. It is the same set of grants the resources’ own access sections show, gathered in one place.

Select Add resource to grant access from here. The list holds only resources you administer, because changing access takes Admin on the resource itself, wherever you do it from. Everyone in the group receives what you add.

For the same reason, Revoke appears only on the resources you administer. Everyone can see the full list, so a maintainer can always tell what being in the group is worth, even where they cannot change it.

When someone has access two ways

A person can hold a direct role and be in a group that holds a role on the same resource. They get the more permissive of the two. Access is never reduced by adding another grant.

Because of that, Astropods disables any direct role that would not raise the person’s effective access. If a group already makes someone an Editor, granting them Viewer directly changes nothing, so the option is unavailable.

Removing a direct role does not remove access that comes from a group. To take away group access, remove the person from the group or remove the group’s grant on the resource.

Archive or delete a group

Archive retires a group without disturbing what it already reaches. Existing grants keep working, and the group shows as a locked row in access panels. You can remove that grant, but you cannot change its role, and the group cannot be given access to anything new. Restore the group to make it usable again.

Delete is permanent. It removes the group and every grant it held, so anyone whose access came only through that group loses it.

Archive when a team is winding down and you want its access to keep working while you unwind it. Delete when the group was a mistake or its access should end now.

Next steps

• Working with accounts: account roles and switching between accounts
• Manually authorize requests: run the same access checks yourself from an agent
• Managing your agents: the deployment surfaces these roles apply to