# Groups and permissions

Groups bring members together. Permissions define what each group can do.

Source: https://docs.rumata.dev/guides/collaboration
Reviewed: 2026-11-01

<a id="permission-model"></a>

## See who has access

1. Open System Explorer → [Permissions](https://docs.rumata.dev/guides/controls-access#groups) → Groups.
2. Use Search groups… to find the team group and select it to see its members.
3. Open Manage access on the resource whose permissions you want to inspect.

Expected result: you can compare group membership with the resource’s grants. If the group is missing, ask its owner to confirm your access before creating a duplicate.

<a id="defaults"></a>

## The groups Rumata creates for you

Rumata creates groups for your account and project. A factory can also have a workflow-backend group or service-key grants when those integrations need them. These are resource permissions, not application-user roles.

| Group you may see | What it is for |
| --- | --- |
| Your private group | Created with your account. It contains you and cannot accept extra members. |
| Project default group | Created with the project, with Read permission on the project. It is not automatically an administrator role. |
| Project admin group | Created with the project, with all project permissions. The creator is included in both project groups. |
| <factory-id>_backend_user_group | A group used by workflow-based backend operations to access their authorized resources. The creator is not automatically added as a member. Its members can be workflows; it is not a default login group for users of a managed-backend app. Inspect the actual membership and grants. |

The [factory backend group](https://docs.rumata.dev/guides/collaboration#defaults) is for the product’s backend work, not a ready-made team role. Do not invite a teammate into it just to let them edit the website.

Public and [All Rumata users](https://docs.rumata.dev/guides/controls-access#permission-meaning) are broader audiences, not your private team. Builder-created HTTP workflows can receive public execution access. That does not make every database record public: the product must still enforce who can read or change each record. Check each resource’s actual grants in [Manage access](https://docs.rumata.dev/guides/controls-access#manage-access).

![Access & Permissions filtered to the factory backend group, with workflow members.](https://docs.rumata.dev/media/manual/groups.jpg)

Reference capture from the separate Sabai Talk Thai application (September 8, 2026). This is the automatically created backend group. Its members are workflows, so it should not be used as a general teammate role.

<a id="invite"></a>

## Give a teammate access

1. Open [Permissions](https://docs.rumata.dev/guides/controls-access#groups) → Groups and select an appropriate team group. To create one, choose New, enter a Name and optional Description, and select Create group.
2. Ask your teammate for their exact Rumata nickname. Enter it in Invite by nickname… and choose Invite. New email and Google registrations use the email address as the initial nickname, but older or provisioned accounts may have a different nickname. This is an account lookup, not an invitation to an arbitrary email address.
3. Have the recipient sign in to that Rumata account and [accept the invitation](https://docs.rumata.dev/guides/invitations). Sending the invitation alone does not add a member.
4. Open [Manage access](https://docs.rumata.dev/guides/controls-access#manage-access) on the intended resource. Add the team group, select only the permissions it needs, and choose Save changes.
5. Have the teammate reopen the shared factory or resource and try the intended action.

Expected result: the recipient is a group member and can perform the granted action. If the nickname is not found, check the exact account nickname and registration status. If the invitation is missing, check the recipient account and whether it was already accepted or declined. If access is denied after acceptance, check membership and the resource grants. Creating a group does not grant access to every resource, and an invitation does not bypass subscription requirements.

![New group dialog with Name, Description, Cancel, and Create group.](https://docs.rumata.dev/media/manual/new-group.jpg)

Reference capture from the separate Sabai Talk Thai application (September 8, 2026). Enter a recognizable team name. Creating the group and granting it access to a resource are separate steps.

<a id="inherited-access"></a>

## If access seems too broad or too limited

Check the resource, group membership, and inherited account-wide access. An account-wide grant applies to its projects and cannot be cancelled by a local denial. A subscription or quota can also prevent work even when someone has permission.

<a id="product-users"></a>

## Your teammates and your website’s users

Team access in Rumata and customer access to your application have separate rules. The backend verifies application sessions and enforces roles and record ownership. Native email/password accounts are available in the Node API starter; reuse existing authentication where appropriate. [Sign in](https://docs.rumata.dev/guides/testing#access) with two test users and verify that private records stay private. Application invitations are separate from Rumata team invitations.

## Related guides

- [Groups, invitations, and access controls](https://docs.rumata.dev/guides/controls-access)
- [Accept an invitation](https://docs.rumata.dev/guides/invitations)
- [Understand plans and usage](https://docs.rumata.dev/guides/billing)