Understand the access model
A role packages the permissions that belong to a particular kind of job, so one role can stand in for many separate permissions. A permission is the finest-grained piece of access, covering a single kind of action on one type of protected item. A role or permission has no effect on someone until an access grant applies it to them, and each grant holds only within a stated scope.
Authentication answers the question of who is making a request. Authorization answers a different question: which actions that identity is allowed to try. Authorization to attempt an action does not prove that a business outcome managed elsewhere was completed. Identity, membership and authorization each answer a separate question, and none of them hands over ownership of a business outcome. Roles are a convenient way to hand out access in bulk, while the conditions on when an action is allowed are checked separately from the role.
Where access is administered
On an implementer record, the Permissions group holds separate Clients and Tools selectors. Which clients an implementer serves is a different question from which tools they may open.
A client record has the tabs General Info, Setting Up Automation and Admin Panel User. An identity for a client is administered apart from the client's own configuration. The Admin Panel User tab has Name, Email, Password and Roles fields. On an existing client, the Name, Email and Roles fields on that tab are disabled.
The Admin Panel menu has separate Admins and Agents entries. The Admins table has Name, Email and Description columns.
Reaching an application is not authority inside it
The Hub Tools page lists a separate Open app link for each application, including Admin Panel, Site Builder and Erp Manager. Opening an application does not by itself authorize actions inside it. Assigned roles and permissions define access, while authorization policies determine whether the action is allowed under the applicable conditions. Administrative controls do not extend your role's authority or replace required approval.
How permissions work for Admin Panel staff
The first administrator has all permissions, and administrators added afterward start with none.
A new administrator or agent account can sign in but opens no section until someone grants it access.
Administrators and agents have separate read and write permissions for each Admin Panel section. Super administrators can assign permissions. Read access lets a person open a section and load its data. Write access lets a person create, update and delete records and perform actions in that section.
Sections without read access are hidden from the sidebar, and controls such as create, edit and delete are hidden or disabled where write access is missing. The platform also enforces these limits on the server, so hiding a menu item is not the only barrier.
A permission edit submits the complete set of sections, so any section left out of the edit is revoked. Review the full list of sections before you save, because an edit that looks like adding one section can also remove others. An edit that changes only other details, such as the name, leaves existing permissions untouched.
An agent needs a sync key to retrieve data: it identifies the agent in the ERP and limits query results to that agent.
Identity and access are decided separately
Knowing who is acting does not by itself determine what that identity may attempt. A grant takes effect only where participation is permitted, required approvals are satisfied, and policy allows access in that environment during the grant's valid period. Signing in confirms who someone is; what they can then reach is a separate matter. The platform's approach is to keep each person's access as small as their job allows, with a way to review it and take it back.
Related