Roles and permissions

A role groups permissions such as reading a table. Assign roles to database identities, then test what they can do. Organization membership controls access to the console and is managed separately.

Screenshots show the current local console with sample data. They do not show live credentials or confirm a production change.

1. 01
   Define the allowed actionsName the tables and operations this role needs.
2. 02
   Assign the database identityAttach the intended role to the user or application.
3. 03
   Test allowed and denied requestsUse that identity’s credentials for both tests.
4. 04
   Review effective permissionsCheck combined roles and policies when access differs from expectations.

1. Review your teamCopy Anchor Link

Return to the organization and open Team. Choose Invite member, enter an email and select an available organization role. In the signed-in console, invitations are emailed. Demo invitations remain in the browser.

2. Open Roles & grantsCopy Anchor Link

Select an instance and open Access Control → Roles & grants. Review the roles, inherited roles and grants returned by that instance. Read the permission explanation if an action is unavailable.

3. Create a database roleCopy Anchor Link

1. Choose New role in a connected console, or New role draft in the local preview.
2. Name it, then choose Grant access for the live role or Add grant in the draft.
3. Select the object and permissions available in the grant editor. Add column masks where required.
4. Save the grant and review the state returned by the instance. Test access using the intended database identity.

Broad object scopes can include more tables than one named object. Review those scopes and inherited roles before granting access. Built-in roles cannot be deleted.

View larger

Name the role and add only the grants it needs.

4. Verify effective accessCopy Anchor Link

Use the connected Effective access view to inspect access for a database identity. In the demo, the similarly named analyzer evaluates local role proposals only.

Verify table grants, inherited roles, row policies and column masks as the intended identity. The demo’s Proposed or Not proposed labels do not establish a live security boundary.

A database role belongs to the database identity layer. Organization Team membership does not provide database permissions. See database identities and the enforcement boundary before applying a proposal.

Edit or remove accessCopy Anchor Link

Return to Roles & grants to edit or revoke a grant. Deleting a custom role requires typing its name and may be unavailable under the current action policy. Read the confirmation and check the returned result before assuming access has changed.

Use the connected organization’s role catalog and permission explanations for its current capabilities. Team membership controls console access; database identities, roles and grants control access to the database. A permission shown in a browser is not a substitute for server enforcement.

Apply through an authenticated serviceCopy Anchor Link

Review exported scopes, resolve database identities, and verify enforcement for SQL, vector, full-text, graph, and direct record requests. A browser draft is not evidence that a user is restricted.

Removing a member or leaving an organization revokes that member’s personal instance tokens. Read the Team page’s confirmation status across the organization’s instances. Review the returned status and follow up on unconfirmed revocations; a removal request alone is not proof that every engine has rejected the old credential. Organization API keys remain separate and are not revoked by member removal; review shared credentials and database identities separately.

Next: prepare row policies and check the live enforcement boundary.