The analyst who could edit her own record
A payroll analyst mentioned it during a design workshop, almost as an aside. She could open her own employee record in edit mode, change her own cost centre, and read the compensation fields on her director's record. She had never asked for any of that, and nobody had granted it on purpose.
The role was fine. It held the permissions an HR operations team genuinely needs. The group was fine too, built from the department and country of the people who do that work. The mistake sat in the assignment that joined the two, where the target population had been left at everyone, and everyone includes the granters themselves along with everybody above them.
That is the most common finding in a SuccessFactors permission review, and carelessness is rarely the cause. People read the model as though a role were a package of access, the way most other systems present it. There are three moving parts, and the third gets skipped.
Roles say what may be done and groups say who does it
A permission role is a list of actions. View a field, edit a section, run a report, change a piece of configuration. It carries no information about which employees the holder may do those things to. That omission is deliberate.
A permission group is a set of people described by criteria instead of by a list of names. Department, division, legal entity, country, job classification, employee class. Groups show up twice in this model, and the second appearance is the one people miss.
An assignment ties a role to a group of granters and to a target population. The granters are the people who receive the ability. The target population is the set of employees whose records that ability reaches. The same role, granted to the same group, with two different target populations, produces two entirely different levels of access. Reading a role on its own tells you almost nothing about what anyone can see.
Target population options vary by module and by release, so confirm yours before designing around them. A target is usually a named group, or the granter's own record, or the people who report to the granter. Some permissions have no meaningful target at all, because they change configuration rather than employee data, and those do not obey a target population.
Build groups from attributes and name roles after what they permit
A group that lists individual people is a maintenance debt nobody services. It looks correct on the day it is built, then someone transfers, someone covers a vacancy for four months, and the list quietly stops describing the people it was meant to. Nothing breaks, which is the problem, because nothing tells you either.
Attribute-based groups fail differently. Access follows the employee data, so a transfer moves someone's permissions with them on the day the data changes. That puts weight on the data being correct and on the feeds that maintain it, which is a fair trade and also a reason to care about integration that survives a reorg and about how worker master data stays consistent with everything downstream.
Name roles after what they permit. The person approving an access request usually sees a role name and a requester name, nothing else. A name that states the permission, something along the lines of edit compensation data for direct reports, lets that approver make a decision. A name built from a project code or a sequence number turns the approval into a formality, and formalities get rubber-stamped.
Fewer broad roles, and the honest cost of them
Every role you create has to be reviewed, tested after each release, explained to an auditor, and understood by whoever inherits your job. Forty roles where twelve would do buys no extra security. What it buys is a review nobody finishes, and unfinished reviews are where stale access lives.
So the default should be fewer and broader. The counterweight is real, though. A broad role grants more than any single holder needs, and on the day someone uses the part they never needed, the design gets the blame. Both arguments are correct, so the skill here is choosing where the line sits rather than picking a side.
The line I use: split a role when the difference between two populations of holders is one an auditor would ask about, such as who can see compensation or who can change organisational structure. Keep a role whole when the difference is cosmetic, such as two departments doing identical work. That test also keeps segregation of duties visible, because the splits you make are the ones that matter in a control review.
Nobody adds up what a person already has
Permissions accumulate. A person who belongs to four groups holds the union of everything those four assignments grant, against the union of the populations those assignments target. There is generally no deny that overrides a grant, so nothing in the model subtracts. Confirm the behaviour for your module and release before relying on it.
The request that lands on your desk describes one addition. It never describes the other three, and the approver almost never looks. Someone moves from recruiting into HR operations, picks up the new group, keeps the old one because the attribute that placed them there has not been updated yet, and ends the week with reach that no single approval ever granted.
The control is easy to state and unpopular to run. Before approving an addition, look at what the requester already holds instead of at what the request asks for. That means a periodic review with the person at the centre rather than the role, the habit that keeps group sprawl in check on other HCM platforms and sits behind identity lifecycle work across applications.
Target population mistakes expose data instead of blocking work
Access errors come in two shapes and only one of them tells you. Grant too little and someone raises a ticket within the hour, because they cannot do their job. Grant too wide and nothing happens, for months, until a person notices something they should not have seen or an auditor asks a question you cannot answer. Target population mistakes are the second shape, every time.
Self-service and manager access deserve separate attention, because both are computed from the reporting relationship held in the employee data. A wrong manager on a record stops being an organisation chart annoyance and becomes a security problem, since a manager assignment usually carries the ability to see pay, performance and personal data for that person. Vacancies, acting managers and matrix relationships all vary by module, so check how each one resolves in your own configuration.
Two cases step outside this reasoning altogether. A proxy grant lets one person work inside another person's access, which means the target population you designed applies to the person being proxied rather than to the proxy holder. Permissions that administer configuration are not bounded by a target population at all. Keep both lists short, review them by name rather than by rule, and know who sits on them today.
Reading the configuration will not tell you what someone can see
The only verification worth anything is to look at the system through the account of a real person in a real position with real data around them. Whatever your release calls the feature for viewing the system through another user, confirm what it is named and who may use it, because the control on that capability matters as much as the check.
Role definitions tell you which permissions exist. They cannot tell you which records those permissions land on, because the answer depends on the target population, on the groups the person happens to match today, and on the reporting line stored on their record. Three configuration screens that each look correct can still add up to someone who can read the executive team.
Pick the people who make the test meaningful. Someone from each major group, one person inside a sensitive population, one line manager with direct reports, one person who sits in two groups at once, and one recent transfer. Then check the same things for every one of them before your next release lands, and again after it.
- Which employee records they can open, and whether their own record is one of them.
- Whether they can reach anyone above them in the reporting line.
- What they can see on a record in a sensitive population, field by field, not screen by screen.
- Which fields they can edit rather than only view.
- What their manager access resolves to when a position above them is vacant.
- Which reports and exports return data, since a report can return what a screen hides.
- Whether any proxy or administrator grant makes every answer above irrelevant.
