#Permissions

Authorization answers three separate questions: which page a person can enter, which business operation they can perform, and which records that operation may use. A sales engineer may edit a quote they prepared but submit it only when they also have responsibility for its project. Opening a page does not grant its data operations.

The main authorization plugin provides permission sets, page, business and administration permissions, and inspection. Default access, sharing and restrictions are optional plugins. If a settings section is missing, ask the developer to check installation and configuration.

Each page under Settings → Authorization is itself an administration permission. Read opens the page; creating, updating and deleting are separate actions, permission sets add Manage assignments, and the inspector needs Inspect permissions. Grant them in the Administration section of a permission set.

Developers or AI coding agents define operations, fields, relations and scope choices, then enforce them on the server. Administrators assign sets and configure scopes/rules. The permission editor does not edit arbitrary database fields; adding a writable field requires changing the business operation's declaration.

Teams/departments require an integrated membership model. A user can hold direct and inherited grants; removing one source does not remove the others. Start with permission sets, then scope rules, AI development requests and inspection.

Unrestricted administrators bypass business scope rules, so use ordinary accounts for validation. Protected set keys cannot be renamed. The default set permits allowed content edits but cannot be deleted or lose its default assignment through generic management. Removing the final active administrator assignment is also prevented.