Creating a Group

Groups are created in the Admin Panel; what they may reach is granted in the Architect Panel. Knowing that split saves a lot of looking.

Where to find it

Architect Panel → Data:

Datastores — the Permissions row action — where the group is granted access

Architect Panel → Security:

Permissions — named permissions
Record Access Roles — row-level grants

To create one: Admin Panel sidebar → User Administration → User Groups → new record.

Admin access

A group carries an admin access level, and it is the field to think hardest about. It governs administrative capability rather than access to any particular datastore, so it is not narrowed by the permissions you grant afterwards.

Leave it at the lowest level unless the group genuinely administers the platform. A group with administrative access and carefully limited datastore permissions is not carefully limited.

Bringing a group into use

Create it with a clear, role-based name.
Grant its datastore permissions via the Permissions row action on Data → Datastores.
Set field-level access where the datastore uses field security.
Add one test user.
Sign in as them and confirm what they can and cannot reach.
Only then add everybody else.

Test with one person first

This is the step people skip, and it is the one that prevents the common failure: a group granted less than intended, added to forty people, each of whom raises a ticket the following morning.

Verifying as a real member takes five minutes. As an administrator it proves nothing, because administrators generally see everything.

Grant nothing by default

Start a new group with no permissions and add what it needs. Copying an existing group is quicker and carries across everything that group had accumulated, including whatever it should not have had.

Write down what it is for

One line, somewhere durable: what role this group represents and why it exists. Groups outlive the people who create them, and the commonest reason nobody removes a redundant group is that nobody is certain what it does.

Do not create a group per person

A group with one member is an individual grant with extra steps. If somebody genuinely needs unique access, that is usually a sign the role definitions need revisiting rather than a new group.

Worked example

A team creates a Reporting group with read-only access to four datastores and no administrative level. One analyst is added and signs in to confirm they can read what they need and cannot edit anything. The remaining six analysts are added the same afternoon, and no tickets follow.

Recommendations

Keep admin access at the minimum.
Start from nothing, rather than copying a group.
Test with one member before adding the rest.
Record what the group is for.