The error that arrives after the tile opens

Two tickets came out of the same plant in the same week on a rollout I was reviewing. A goods receipt clerk could see the posting application on her home page, opened it, keyed in the delivery and got told she had no authorisation for that plant. Her shift supervisor held every authorisation the posting needed and could not find the application anywhere.

The service desk handled them separately. Security added the missing plant value for the clerk. The launchpad team put the application on the supervisor's page. Both tickets closed inside a day. Nobody asked why the two had arrived together, and a month later the same pair came in from a different plant.

They were one problem seen from two sides. What a user can see and what a user may do come from two related sets of configuration, held in different places and usually maintained by different people. Content assignment decides whether an application shows up. The authorisation check inside the running application decides whether the work goes through. Nothing keeps those two aligned except somebody deciding to keep them aligned.

Visibility and permission come from different places

The model is simpler than the ticket queue suggests. A business catalogue says which applications exist as a set and may be handed out. Groups and spaces decide how those applications are laid out for the user, which page they sit on and in what order. A business role ties a content assignment to the people who hold that role.

Separately from all of that, the application checks authorisation objects with fields and values while it runs. Assigning a catalogue pulls the related authorisation defaults into the role, which is helpful and incomplete. The values your business cares about still have to be maintained, organisational values above all. A role carrying the posting application with no plant value produces that clerk's ticket every time.

So visibility is not permission, and permission is not visibility. A user can hold everything a posting needs and see nothing, because no page was ever arranged for the job she does. A user can see a full page and be stopped at the first action, because the values behind those applications were never filled in. Both states are ordinary in a system nobody has reconciled on purpose.

Where you maintain each part depends on your release and your deployment. Spaces and pages replaced groups as the default arrangement partway through the S/4HANA line, an embedded launchpad keeps content somewhere different from a separate front-end server, and the cloud and on-premise editions differ again. Confirm which model you are on before copying a procedure from a colleague at another company.

Build the role around the job, not the application list

Roles that survive describe a job somebody is accountable for. Goods receipt in one plant. Accounts payable for one company code. Internal audit with read access across the group. Name the job, then let the content follow from it. The role keeps its meaning when the applications behind the job change, and they will.

Roles built the other way round start as a list of applications somebody asked for, and the name records that list. Then a release splits one application into two and retires a third, and the name describes nothing anybody recognises. Nobody can say whether a new application belongs, so it gets a role of its own. Three years of that and you have several hundred roles and nobody able to review them.

A job-shaped role also answers the question a security review actually asks, which is whether one person can approve what they created. You cannot see that in a list of tile names. You can see it in a role that states the job. Segregation of duties when one person wears four hats gets much harder when roles are named after screens, and role-based permissions in SuccessFactors rewards the same habit.

Assign at the catalogue level and keep presentation separate

Assign business catalogues rather than individual applications. Per-application assignment looks more precise for the first dozen roles, then turns into the maintenance nobody will take on. Every release, somebody has to decide one application at a time whether each addition belongs in each role, and there is no shortcut once the inventory is your unit of assignment.

Catalogue-level assignment moves the decision up a level. The catalogue stands for a scope of work, so when delivered content changes you review the scope instead of the inventory. You give up some precision, and I would take that trade nearly every time. Where a catalogue really is too broad for a population, restrict it by values once rather than pulling applications out of it by hand.

Keep presentation apart from permission and you can reorganise what people see without reopening what they may do. A business unit that wants its own page arrangement gets one, and the security team does not have to review the change. Mix the two and every cosmetic request becomes an authorisation discussion, which is how a launchpad tidy-up ends up waiting two quarters for a slot.

Where this breaks two years in

The copied role is the most common trap I find. Somebody copies a delivered business role, adjusts it and ships it, and the copy stops receiving whatever SAP changes in the original. Two upgrades later the delivered role has new applications and a reworked catalogue, while your copy holds the shape it had on the day it was taken. Put that comparison in the upgrade plan with a name against it.

Skip it and you hear about it from a user instead, usually one who has kept a task in a spreadsheet for eight months because the application built for it landed in a catalogue she was never given. The more content you have copied and modified, the more of each release you own, which is the same arithmetic behind clean core as a budget decision.

The second trap is accumulation. A user collects content from four or five roles, each sensible on its own, and ends up with a home page carrying sixty applications arranged by nobody. No role owner is responsible for the combined result, so nobody repairs it. Give that result an owner for each major population, and review it with somebody who does the job daily.

The last one catches people out. A user can reach an application by following a link from another application, without that application ever appearing on a page. Display is a subset of assignment, and links resolve against what is assigned. So a report you pulled off every page stays reachable for anyone whose catalogue still carries it. When you take something away, take it out of the assignment and not just the layout.

Test in a real role and keep the reasoning

Reading configuration proves nothing. Take a test user, give it exactly one production role, sign in and do the whole task, including the posting step and the one after it. Half the problems I have seen would have been caught by one person spending twenty minutes doing the job the role claims to support. Run the same script after every upgrade.

Failed authorisation checks are the signal that content and permission have drifted. They pile up quietly, because users work around them and stop reporting them after the second try. Have your Basis team pull the record of failed checks on a regular cycle, group them by role, and count a repeated failure on a visible application as a design fault rather than a missing value.

Then write down why each role contains what it contains. Not the list, which the system already holds, but the reasoning. Which job, which population, which scope, who agreed to it and when. That record makes the next review possible, and it is the first thing to go when the consultant who set it up moves on. The same instinct sits behind a runbook for the week you are away.

Before the next upgrade window, work through this with each role owner.

  • The job this role describes, in one sentence a line manager would recognise.
  • The business catalogues it assigns, and why each one is in scope for that job.
  • The organisational values a holder of this role needs, and who maintains them.
  • Whether it is a copy, and when it was last compared against the delivered original.
  • Who owns the page arrangement this role's users actually see.
  • Which applications are reachable by a link from here but shown on no page.
  • Who approved the last change, and on what date.