RumataGroups and permissions
Groups bring members together. Permissions define what each group can do.
Step-by-step guidance.
See who has access
- Open System Explorer → Permissions → Groups.
- Use Search groups… to find the team group and select it to see its members.
- 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.
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 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 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.
Give a teammate access
- Open Permissions → Groups and select an appropriate team group. To create one, choose New, enter a Name and optional Description, and select Create group.
- 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.
- Have the recipient sign in to that Rumata account and accept the invitation. Sending the invitation alone does not add a member.
- Open Manage access on the intended resource. Add the team group, select only the permissions it needs, and choose Save changes.
- 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.
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.
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 with two test users and verify that private records stay private. Application invitations are separate from Rumata team invitations.