Product · Governance & security
Give people access automatically based on their role, department and location, providing exactly as much as needed. This keeps you in control: you know and can prove who has access to what, and no employee retains permissions that no longer match their role.
"Just give him the same permissions as Kees"
This is how access grows in most organisations: someone gets the permissions of a colleague, who had too many to begin with, and no one ever cleans it up. For IT, this means weekly hassle with tickets. For the security officer, it is a dormant risk: permissions that no one can explain anymore, former roles that linger, and no answer to the question "who actually has access to our financial data?".
Roles solve both. You define what a job profile needs just once, and Joinly automatically assigns that access to everyone in that role, and revokes it as soon as the role changes. Less manual work for IT, and for security: least privilege that enforces itself, demonstrably.
01
New employee: exactly the right package
The role determines the groups, licences and apps.
What it delivers: zero open tickets, and no "just in case" excessive permissions.
02
Job change: access that moves with you
Old roles expire, new ones are added. The benefit: no rights creep during internal transit: the biggest silent leak in most organisations.
03
Contractors & interns: access with an expiry date
Roles and permissions are assigned an end date. The benefit: external users never retain access longer than agreed.
Manual or conditional
A role is a bundle of access: Entra groups, Microsoft licences, Enterprise Applications and plugin apps. You assign it manually (for exceptions) or conditionally: automatically to everyone who meets your conditions: department, job title, location or any other field. HR changes an attribute, and the access moves with it.
Conditional roles are your authorisation matrix: only it executes itself and stays up to date, instead of gathering dust in Excel.
Four building blocks that turn RBAC into a security tool.
For the security officer
Know and prove who has access to what
Most organisations do not come to us for "more convenient account management", they want grip: to know for sure that no one has access that does not belong to their role, and to be able to prove this during an audit or under NIS2. Roles make that possible:
Control over access
Roles that are correct. And stay correct
Roles determine who has access to what, workflows govern what follows, and role evaluation aligns the model with reality. This is how you gain control over access — and keep it.
01
Roles determine who, workflows determine what
A role controls the access that directly belongs to it. Do you want more to happen as soon as someone is assigned or loses a role (a welcome email, a service desk ticket, an account in another system)? Then you link a workflow to assigning or revoking the role. Roles determine who gets what, workflows determine what happens then.
02
Securely migrate to RBAC
The most exciting moment of any RBAC project is its implementation. Before any change is made, the role evaluation reveals who should have the role versus who actually has it, allowing you to apply the difference with a single click. This is how you migrate role by role, with your eyes wide open. For security, this is your baseline: the discrepancy between actual and intended access is your first risk list.
Ask us anything