myWork24 controls who can do what through roles and permissions (RBAC). This guide explains the model in plain terms and shows you, as an administrator, how to grant people the access they need.
The building blocks
A few terms are worth getting straight up front:
- Permission — a single capability, such as view Purchase Orders or dispatch a Sales Shipment. Permissions are defined in code and appear automatically in myWork24; you can browse them but you cannot create, rename, or delete them from the admin screen.
- Application Role — a named bundle of permissions (for example, Floor — Local Receipt). This is what you actually assign to people.
- Application Group — a bundle of roles. Assign one group and the user gets all the roles inside it in a single action.
- Job position — a user's current HR position can automatically confer roles, so everyone in that position inherits the right access.
How access adds up
A person's effective access is the union of everything that reaches them: roles you assign directly, roles from any groups they're in, and roles from their job position. If any one of those grants a permission, the user has it.
Assign roles, never single permissions. myWork24 uses role-only access — people receive permissions only through Application Roles, Groups, or their job position, not one permission at a time.
The golden rule for admin access
Never give a person the raw ADMIN permission directly. Instead, assign the built-in System Admin role — an Application Role whose one permission is full administrator access. Anyone holding an admin role passes every permission check automatically.
Granting access from the admin screens
Everything lives under Admin → Roles & Permissions. The screen has three tabs:
- Application Roles — the list of roles. Click a role's name to open it, or use New App Role to create one.
- System Permissions — a read-only catalogue of every permission, plus a "Who has it?" view that shows which roles and groups grant each permission.
- Groups — create and manage Application Groups (bundle roles together and assign users).
To give someone access:
- Decide which role fits what they do (for example, Floor — Purchase Orders for a goods-in receiver).
- Open Admin → Roles & Permissions → Application Roles and click that role.
- Go to its Users tab and add the person. They gain the access at their next login.
To manage a role's permissions, open the role and use its tabs — Details, Permissions, Users, and Job Positions:
- On Permissions, tick the capabilities the role should include.
- On Users, add or remove members directly. Anyone who inherited the role via a group or their position is shown read-only with a tag.
- On Job Positions, attach the role to one or more HR positions. Everyone currently in that position inherits the role automatically — the most efficient way to grant access by job rather than person by person.
Role and permission changes take effect at the user's next login, not immediately.
The exception: area, warehouse and product access
Some access is scoped to specific places or products — which warehouse areas a person can move stock in, which products they can see, and so on. This typed scheme is separate from roles and is still granted directly to the user on their admin profile, not through an Application Role. So a mover who holds the Move Order — Mover role also needs the matching area access (for example, on Stores) before they can actually collect and drop stock.
Managing roles over the API
Everything above is also available through the REST API for tooling and integrations, under /rest/v2/app-roles and /rest/v2/app-groups. These endpoints let you list, create, and edit roles and groups, and assign or remove members and job positions. Every one of them requires the RBAC-admin permission, so only administrators can change access this way.
Whether you use the screens or the API, the result is the same access model — so pick whichever fits your workflow.