The Permissions page in Zeroplat is the control center for managing access rights within the application. Permissions ensure that only authorized users can view, open, or interact with specific pages, menus, and actions.

In Zeroplat, permissions can be assigned on three levels:

• Role-based – Assigned to all users belonging to a specific role (e.g., Admin, Manager).
• User-based – Assigned directly to individual users.
• Organization-based – Assigned to an entire organizational unit, enabling group-level access control.

How Permissions Work

1. Page Visibility
   • For a user to see a page in the navigation menu, they must have permission for at least one action on that page.
   • If no permissions are granted, the user will not see the menu item at all, and cannot access the page.
2. Actions
   • Each page is associated with one or more actions (e.g., Save, Approve, Reject).
   • Actions typically appear at the top section of the page (buttons or operations).
   • Permissions control whether these actions are available to the user.
3. Granular Control
   • Example: A user may have permission to view a page but not to edit it.
   • This allows administrators to create precise access rules depending on business needs.

Example (from screenshot)

• The Address Entry screen has an action called Save.
• The permission Administration.Account.Address.Save is created for this action.
• This permission has been assigned to the Admin role.
• Result: All users with the Admin role can see the Address Entry screen in the navigation menu and perform the Save action.

Permissions Logic Diagram

[User]
   ├─ belongs to → [Roles] ─┐
   ├─ is member of → [Organization Units] ─┐
   └─ has direct → [User Permissions]      ├──► (UNION) = Effective Permissions
                                            │
[Page]
   └─ defines → [Actions: View, Save, Approve, Reject, ...]
                       ▲
                       │   if (Effective Permissions contains ≥1 action on this Page)
                       └──► Page appears in left navigation & can be opened
                           else ► Page hidden / not accessible

Once inside the Page:
   Buttons/operations shown = only those Actions the user has permission for

Evaluation Rules

1. Assignment levels: permissions can be granted to Roles, Users, and Organization Units.
2. Effective permission = UNION of all three sources for the signed-in user.
3. Menu visibility rule: a page is visible/openable iff the user has at least one action permission on that page.
4. Action visibility rule: only the permitted actions render (e.g., user sees Approve but not Reject).
5. Workflow steps (Approver state): actions created in the designer (e.g., Approve, Reject) automatically appear in Permissions, where you assign them to roles/users/org units. Items drop into Inbox only for users who have permission on the current Approver action(s).

Quick Pseudocode

effective = user.direct_permissions
          ∪ permissions.from(user.roles)
          ∪ permissions.from(user.organization_units)

pageVisible = any(action ∈ page.actions where action ∈ effective)

renderedActions = { action ∈ page.actions | action ∈ effective }

Practical Examples

• Example A (see page, limited actions):
  • Granted: Administration.Account.Address.Save to role: admin
  • Result: Admins see Address Entry in the menu and the Save button only.
• Example B (workflow approval):
  • Approver state defines Approve and Reject.
  • Permissions assigned to org unit: Finance.
  • Result: Finance members see approval items in Inbox and both buttons on the page.
• Example C (hidden page):
  • No actions on a page are granted to a user/role/org unit.
  • Result: Page does not appear in left navigation and cannot be opened.

Troubleshooting Checklist

• Page not visible? → Confirm at least one action on that page is assigned to the user (via role/user/org unit).
• Button missing? → Check the specific action permission (not just page-level).
• Inbox empty? → Verify the current Approver step’s actions are granted to the user’s role/user/org unit.

If you want, I can turn this into a small “Permissions” section in your docs with consistent headings and examples inline.

Key Benefits

• Security: Prevents unauthorized users from accessing sensitive screens or actions.
• Flexibility: Permissions can be given at role, user, or organizational unit level.
• Clarity: Users only see the menus and actions they are allowed to use, reducing confusion.

📌 Summary:
The Permissions page defines who can see and interact with resources in Zeroplat. A user can only see a page in the navigation menu if they hold permission for at least one action on that page. Permissions are highly flexible, supporting role-based, user-based, and organization-based access control.