Role Changes Not Reflected Until Relogon

Helpdesk ticket usually reads something like: security added the role this morning, PFCG shows it assigned, but the user still cannot see the new tile or still gets the authorization error on the same transaction they were promised access to an hour ago. Sometimes the opposite happens, a role was removed because someone left a project, and the user can still execute the transaction that was supposed to be locked down. The business frames it as the role change did not work or the fix did not take. It often comes back a second time from the same user a week later after another role update, because nobody explained that a session boundary is involved, so every change looks unreliable to them even when the configuration side is fine.

Pull SU56 for the user while they are still complaining, compare the profile list shown there against the profile currently generated for the role in PFCG; a mismatch confirms the buffer or user master is stale rather than the role definition being wrong. Cross-check the user comparison status on the role's user assignment tab at the same timestamp. If several users on the same role show the identical gap, check the mass comparison job log for failures around the date the role was last changed.

If the buffer is simply stale and the user master record is correct, the fix is a logoff and logon; nothing needs to be transported or changed. If the user master comparison was never run, running the comparison, either targeted at the single user or as a mass comparison covering all users of the affected role, is a data action performed in the production system directly and does not need a transport by itself. If the root cause is a composite role whose comparison indicator was overlooked, compare the composite role as well, since comparing only the single role does not always propagate. If the gap is in a CUA child system, re-trigger distribution and run the comparison locally in that client; this is still a data step, not a transport, but it depends on the RFC connection between central and child systems being healthy. If the underlying issue is a config problem, such as a derived role never regenerated after its parent's org values changed, that regeneration is also a data-side action inside PFCG, but if the org level structure itself was wrong, correcting the org level value definition is a configuration change that does need to move through the transport landscape in the normal sequence.

The habitual response is telling the user to log out and log back in every time, treating it as the permanent fix rather than checking whether the user master comparison ever ran. This works once by accident when the buffer really was the only issue, then fails the next time the true cause is a missed comparison, making the whole process look unreliable. A worse variant is granting the missing authorization object directly to the user through SU01 extras to make the ticket close faster; this bypasses the role entirely, creates an authorization the role model does not track, and shows up later as an audit finding with nobody able to explain why the user has it outside any role.

Owned by the security or GRC role administration team, since running the user master comparison and confirming role generation status sits with them. Basis is pulled in only when the periodic comparison job itself is broken or when a CUA RFC connection is down. The handover note should carry the user ID, role and composite role names, the timestamp the role was last changed, the comparison indicator status at time of ticket, and whether the landscape uses CUA.