Missing Authorization Object After Transaction Change

A user who has run a transaction for months suddenly gets a short dump or an authorization error screen after a system upgrade, a support package application, or the rollout of a custom transaction variant. The business description is usually something like 'this worked yesterday, nothing changed on my side' or 'it broke after the weekend patch'. Sometimes it is reported by a whole team at once, right after a transport of a role change that was supposed to be unrelated. Occasionally the complaint is narrower: one specific field value or sub-screen within the transaction fails while the rest of the transaction works, which points at a single authorization object rather than the whole role being broken. Helpdesk usually escalates it as 'role is missing an authorization' once someone has run an authorization trace, but nobody yet knows why the object is missing.

Pull the trace log for the exact user, transaction, and timestamp of the failure and extract the object, field, and value that was checked and rejected. Cross-reference that object against the SU24 proposal for the transaction to confirm whether it is present there at all. Then compare the role's current authorization tree against that same SU24 proposal; a gap between the two, with the object present in SU24 but absent or manually flagged in the role, is the evidence that closes the root-cause question.

If SU24 already has the correct proposal but the role is stale, this is a role data fix: open the role in PFCG expert mode, run the comparison against SU24, add the missing object with the correct field values, and regenerate the profile. If the role is transported between systems this change still needs a transport, but it is a role transport, not a customizing change. If SU24 itself is missing the object because SU25 was skipped or the object was never registered for a custom transaction, that is a configuration gap and must be fixed at the SU24 level first, then propagated to roles, and this SU24 change does travel through a customizing transport request. If the object was deliberately deleted and marked manual, decide whether the restriction was intentional; if not, remove the manual flag and let the merge repopulate it, then re-apply any org-value restriction properly through derived roles rather than by stripping the object.

The common reflex is to open the role in PFCG expert mode and manually add the object with the values suggested by the SU53 or trace output, save, generate, and close the ticket. This clears the immediate error but does not touch SU24, so the underlying proposal is still wrong. The next time the role is regenerated from the menu, or the next time someone runs a mass comparison across roles, the manually added object can be treated as inconsistent with the proposal and either flagged or dropped again, reopening the same ticket weeks later under a different user's name.

Security or GRC administration owns SU24 maintenance and role generation and is the party who runs the PFCG comparison and closes the immediate access issue. The functional or development team that introduced the transaction change owns notifying security when a new authorization check is added, since security has no visibility into new AUTHORITY-CHECK statements without that handover. The handover note should record the transaction, the missing object, whether SU25 was run for the relevant release, and whether the fix was applied at SU24 level, role level, or both.