Manage Permissions

Permissions control which data a user can access or modify and which APIs, Actionflows, AI Agents, and payment capabilities they can call. Momen enforces permissions on the backend, so frontend conditions and component visibility should not be the only access controls.

How permissions work

A role is a set of permissions that can be assigned to multiple users.
A user can have multiple roles. Their effective permissions are the union of the permissions granted by those roles.
Data permissions control access to tables, fields, and rows.
Action permissions control access to APIs, Actionflows, AI Agents, and payment capabilities.

Momen provides two built-in roles:

Logged-in User applies automatically to every signed-in user.
Anonymous User applies to users who are not signed in.

Developers have full data access in the editor. Test production permissions with a user who has the target role.

Roles, data permissions, and action permissions in Momen

Permission workflow

Create a role

Open Settings → Permissions. In addition to the built-in roles, you can create custom roles for your application.

Plan	Custom roles
Free	0
Basic	1
Pro	10

Select Add and enter the role name.

⚠️

A role name cannot be changed after it is synced to the backend. Use a stable, descriptive name when creating the role.

Adding a role in Momen

Set data permissions

Select a role and table, then set table-, field-, and row-level permissions. If a user has multiple roles, every permission granted by any of those roles contributes to the user’s effective permissions.

Table-level permissions: Control whether the role can create, query, update, or delete records, and whether it can query aggregate results such as count, sum, and average.
Field-level permissions: For operations that support field configuration, further restrict which fields the role can access or modify. For example, allow users to update an order status without allowing them to change the user who owns the order.
Row-level permissions: Use Advanced Filtering to limit which records an operation can affect. For example, add a condition that the order creator equals the current user so regular users can access only their own orders.

A minimal “users can update only their own orders” setup includes:

Allow the regular-user role to query and update the order table.
Exclude fields that users must not update.
Add an “order creator equals current user” filter to both query and update permissions.

If another role grants the user broader access, the effective data scope also expands.

Set action permissions

Action permissions control whether a role can call APIs, Actionflows, AI Agents, and payment capabilities. Except for payments, Advanced Filtering can further restrict access based on call inputs, such as requiring a specific Actionflow input to be present.

Setting action permissions in Momen

Actionflow permission checks apply as follows:

Calling an Actionflow from a page or component checks the current user’s permissions.
Calling an Actionflow directly through an API checks the calling user’s permissions.
System Triggers are not restricted by user-role permissions.
Calling an Actionflow from another Actionflow is not restricted by user-role permissions.

Apply permission changes

After changing role definitions, data permissions, or action permissions, use Sync changes or Publish before the new configuration takes effect in production. Saving the configuration alone does not change the current production version.

Assign roles to users

After configuring permissions, assign or remove user roles in either of these ways:

Manual assignment: Select a user in Permissions and update their roles.
Automatic assignment: Use permission-related Actionflow nodes, such as assigning a VIP role after a payment completes.

Assigning or removing a user role takes effect immediately. It does not require Sync changes or republishing.

Assigning a role to a user in Momen

Assigning a role through an Actionflow in Momen

Verify and troubleshoot permissions

Test both allowed and denied operations as an anonymous user, a logged-in user, and users with relevant custom roles. A denied request returns an error similar to:


{
  "data": null,
  "errors": [
    {
      "errorCode": 403,
      "extensions": { "classification": "TABLE_ACCESS" },
      "message": "User 1 has no permission for SELECT on order"
    }
  ]
}

The error uses a shortened user number: User 1 represents the user whose ID is 100000000001. SELECT on order means that the user cannot query the order table.

Check the following in order:

The user has the expected role.
The role has the required table- and field-level permissions.
Row-level filters allow access to the current record.
Action permissions allow the current call path and inputs.
The permission configuration has been synced or published.

For other error patterns, see the Error Reference.