Walk into almost any HR platform and you will find a short list of roles waiting for you. Admin, Manager, Employee, and maybe one or two more. It looks tidy, and it is the first thing that breaks. The moment a real organisation tries to map its people onto those boxes, the boxes turn out to be the wrong shape.
Consider what actually sits inside a modern people function. There is a team that lives in skills and competency frameworks. There is a separate team that runs performance cycles and calibration. There is a learning and development team that builds pathways and content and cares about completion and engagement. There is comp, there is HR operations, there is a CHRO who needs the strategic view. These are not variations on one job. They handle different data, they answer to different pressures, and the harm of showing any one of them the wrong thing is different in each case.
Give all of them a single "HR Admin" role and you have made two mistakes at once. You have handed the learning coordinator visibility into compensation and performance ratings they have no reason to touch, and you have handed the performance lead the ability to edit a competency framework they should only be reading. One of those is a security and privacy problem. The other is a workflow problem. Both come from the same root, which is a role built around a department name instead of around what a person actually does.
The two ways coarse permissions fail
The access-control literature has names for what happens next, and HR teams feel both of them keenly. The first is over-provisioning, the polite term for a role that grants far more than the job needs. A performance manager who can also see and edit skills data, learning records, and survey responses is carrying access that never maps to their work. Nothing bad has to happen for this to be a liability. It is a liability the day it is granted, because the blast radius of a mistake or a compromised account is now the whole platform rather than one corner of it.
The second is privilege creep, and it is slower and more corrosive. People move. A learning specialist covers a performance cycle for a quarter, picks up the access to do it, and keeps that access long after the cover ends. An HR generalist gets a one-time exception to see a pay band during a review and it never gets revoked. Over a couple of years, in a platform that only speaks in coarse roles, half the team ends up able to see things nobody remembers granting, and no audit can cleanly say why. HR data is the most sensitive dataset most companies hold, second only to finance, and it is precisely the dataset most often governed by roles that were never designed for it.
A permission model built on department names ages badly. Every person who moves teams leaves a trail of access nobody deliberately gave them.
The real question is what a person does, not what they are called
The fix is not more roles. Piling on new roles to cover every combination is how you get role explosion, the failure mode where a platform ends up with two hundred near-identical roles that differ by one checkbox each and become their own management nightmare. The fix is to stop thinking in job titles and start thinking in two simpler questions that, together, describe any legitimate access precisely.
- What actions this person needsThe first question is what actions this person needs. Not "do they work in performance," but concretely: can they view a performance cycle, can they create one, can they edit one, can they delete one. View, add, edit, and delete are not one permission, they are four, and most real jobs need only some of them. A learning coordinator building pathways needs to create and edit content, but has no business deleting a competency framework. A performance lead running a cycle needs to create and manage reviews, but should only be able to view the skills data that feeds them.
- Whose dataThe second question is whose data. A team lead reviewing their own people needs to see performance for their team and nobody else's. An L&D manager measuring programme impact might need to see completion across the whole organisation, but only at an aggregate level, with no individual survey responses attached. "View performance" is not one permission either. "View my team's performance" and "view everyone's performance" are worlds apart in sensitivity, and a serious model treats them as different grants.
Cross those two questions, the action and the scope, and you can describe exactly what any person should be able to do without ever reaching for a blunt title. This is the shift the rest of the software world already made, from roles that bundle everything to permissions that combine cleanly, and it is overdue in HR precisely because HR data deserves it most.
Why most tools quietly cap what you can build
Here is the part the demos never dwell on. Almost every incumbent HR and talent platform will happily show you a permissions screen, and almost all of them are limited in one of two ways, and often both. Understanding those limits is the fastest way to see why this matters.
The first limit is a fixed set of roles. You get Admin, Manager, Employee, and perhaps HR Admin, and that is the menu. You can toggle a few things inside each, but you cannot create a genuinely new profile shaped around a job the vendor did not anticipate. So when your skills lead and your L&D lead both need something that does not match any of the four boxes, you do the thing every HR team ends up doing: you over-grant. You give them the nearest role that contains everything they need, plus a pile of things they should never see, because the tool gave you no way to draw the line more precisely. The product forced the over-provisioning.
The second limit is subtler and, in a way, worse. Some platforms do let you create custom roles, but with no data scope attached, so a permission is all-or-nothing across the whole organisation. "View performance" means view everyone's performance, full stop. There is no "view my team only." A team lead who should see six people ends up able to see six thousand, not because anyone decided that, but because the model had no way to express the smaller grant. And once a permission is that blunt, the honest options are to withhold it entirely, which breaks the workflow, or to grant it fully, which breaks the privacy. Neither is a real choice.
Between these two limits sits the trap that makes buyers reach for the wrong fix. When a fixed-role tool cannot express what you need, the vendor's answer is usually to add another role, and then another, until you are staring at dozens of near-identical roles that differ by a single checkbox. This is role explosion, and it is not a sign of flexibility, it is the scar tissue that forms when a rigid model is stretched to cover a reality it was never built for. Every one of those roles has to be maintained, audited, and reasoned about, and within a year nobody can tell you the difference between "Manager" and "Manager 2" without opening both.
A platform that answers every new need with a new role is not giving you flexibility. It is handing you a maintenance problem dressed up as a feature.
The way out of all three problems is the same, and it is structural rather than cosmetic. You stop shipping roles as the unit of access and start shipping capabilities and scopes as the unit, and you let people compose. That is a different foundation to build on, and it is the one we chose.
What we built
This is the thinking behind Lumofy's new permissions module, and I want to show it rather than just describe it, because the design choices are the argument. Instead of a handful of fixed roles, the module lets you compose a permission profile module by module, across the whole platform, at the level of the specific action.
A permission profile is built module by module. Each capability, viewing the workforce intelligence map, managing users, editing a competency framework, running a performance cycle, is its own toggle, and each one carries a data scope. This is a Manager profile scoped to their own team, not the whole organisation.
Two things in that screen matter more than they look. The first is the scope selector sitting beside each capability, the "Own Team Only" control. That single choice is what separates a manager who can see their own team's workforce map from an admin who can see the organisation's. The same capability, viewing the intelligence map, becomes a completely different level of access depending on the scope attached to it, and the model treats that scope as a first-class part of the grant rather than an afterthought.
The second is quieter and, to me, the part I am most proud of. The system understands when a combination of permissions does not make sense and refuses to let you build it. If you scope a manager to view only their own team, the platform will not let you also grant them the ability to add new users across the company, and it tells you why in plain language. Incoherent access is not just discouraged, it is prevented at the point of creation, which is exactly where every access-control guide says the enforcement has to live and where almost no HR platform actually puts it.
Profiles that match how HR actually splits the work
The reason this matters in practice is that it lets you build permission profiles around the real shape of a people team, rather than forcing the team into three generic roles. Three examples make the point, and they are the three profiles most of our customers reach for first.
- The skills-focused profile. For the person who owns the competency framework and the workforce intelligence map. They can view and edit the framework, see the skills map across the organisation, and manage assessments. They have no access to performance ratings or compensation, because their work never touches those, and the model makes that separation clean rather than assumed.
- The performance-focused profile. For the person running review cycles. They can create, schedule, and manage performance cycles, and they can view the skills data that feeds a fair review, but only view it. They cannot edit the framework underneath, and depending on their level they are scoped either to their own team or to the organisation, so a team lead and an HR business partner draw from the same capability at different scopes.
- The learning-and-development profile. For the person building pathways and content. They can create and edit courses, pathways, guides, and the rest of the content library, enroll talent, and manage what is visible. They can see engagement and completion to measure impact, and they are kept away from the individual performance and pay data that would turn a learning tool into a surveillance one.
And these three are only the obvious starting points. The module does not cap you at a fixed number of profiles, because the profiles are not a list we maintain, they are compositions you build. If your organisation needs a talent-mobility profile that can see the skills map and succession data but touch nothing else, you build it. If your works council or a regional data regulation requires a profile that sees engagement results only in aggregate, with individual survey responses walled off, you build that too. A compliance auditor who needs read-only visibility into everything and edit rights to nothing is a two-minute composition, not a support ticket to your vendor. The number of profiles you can create was never meant to be a licensing tier or a hard limit, it simply matches however many distinct jobs your people actually do.
This is the difference that compounds over time. A fixed-role tool asks you to squeeze your organisation into its assumptions, and every mismatch becomes either an over-grant or a workaround. A composable model asks the opposite question, what does this specific person do and whose data do they need, and then lets you answer it exactly, every time, for as many distinct answers as your organisation has. As you grow, add functions, enter new markets with new privacy rules, or restructure, you are not filing feature requests and waiting. You are composing the profile you need and moving on.
Primary roles for the common cases, and permission sets for the profiles you compose yourself. The point is not the two roles shown here, it is that you are never limited to them.
Why permissions are a trust feature, not a settings page
It is tempting to file all of this under administration, a settings screen you configure once and forget. I would argue the opposite. In a platform that holds skills, performance, learning, and engagement data on every employee, the permission model is the single most direct expression of how much the organization can trust the system with its people. Every other feature we build assumes that the right person is looking at the right data, and the permissions module is the thing that makes that assumption true.
Get it wrong and the failures are not abstract. A performance rating seen by the wrong colleague, a pay band visible to someone who should never have had it, a learning coordinator who can quietly alter the competency framework a whole company is measured against. Each of those is a breach of trust that no amount of good analytics elsewhere can repair. Get it right and something quieter happens, which is that people stop worrying about the system and start using it, because they can feel that it sees only what it should.
HR stopped being one job a long time ago. It became a cluster of distinct crafts, skills, performance, learning, engagement, each with its own data and its own duty of care, and the software that serves it has been slow to catch up. Handing all of those crafts a single login was always a compromise, tolerated because the alternative used to mean either a rigid list of roles or an unmanageable sprawl of them. It no longer has to. When you can compose access from what a person actually does and whose data they actually need, the compromise disappears, and the permission model stops being the weakest part of the platform and becomes the part that quietly earns the right to hold everything else. That is the standard we are building Lumofy's permissions to meet, and if you run a people team that has outgrown three generic roles, it is worth a closer look.
FAQ
Role-based access control (RBAC) ties permissions to roles, and each person gets their access by holding a role. In HR software it works when the role reflects what the person actually does and whose data they need. A role built around a department name usually grants far more than the job requires.
Over-provisioning is a role that grants more access than the job needs, such as a performance manager who can also edit skills data, learning records and survey responses. It is a risk from the day it is granted, because a mistake or a compromised account can reach the whole platform.
Privilege creep is access that builds up as people move between tasks and teams. Access granted for a temporary cover or a one-time exception is never revoked, until people can see data nobody remembers giving them.
Role explosion happens when a platform answers every new need with a new role, until it holds dozens of near-identical roles that differ by a single checkbox. Each one has to be maintained and audited, which turns permissions into a management problem of their own.
Define access by two things: the actions a person needs (view, add, edit, delete) and the scope of data they need (their own team or the whole organisation). Combining the two describes any legitimate access without creating a new role for every case.
