Background Job Authorisation Failures

The complaint arrives as 'the overnight job failed' or 'the interface that runs every hour stopped picking up files last night'. Someone opens the job log in the morning and sees the job cancelled with a short status message about missing authorisation, or a program-specific error that on closer reading is an authority-check failure. Often the business framing is timing-based: 'it worked last week', 'nobody touched anything', 'the same job runs fine when I execute it manually in the foreground'. That last detail matters, because it usually means the job step user and the person reporting the issue are not the same user, and the authorisation gap is specific to the batch user's role assignment, not to the program logic itself. Sometimes the report is vaguer still: a chain of dependent jobs all failed because the first one in the chain aborted early on an authority check.

Start in SM37: pull the job log for the failed run, note the exact time, the job step user (not the user who scheduled it, they can differ), and the literal error text. Check ST22 for a matching short dump if the failure came from an authority-check inside ABAP rather than a job-scheduling check. If the failure can be reproduced by running the same report interactively as the job step user, SU53 immediately after the failed attempt shows the last object and value that failed the check; for a purely background reproduction, a system trace in ST01, or a dedicated authorisation trace on newer releases, gives the same detail without needing to log on as that user. Then go to SU01 and check the job step user's lock status, validity dates, and current role assignment as of the failure date. Compare that against the role content in PFCG for the object and value the trace flagged. Use SUIM to check when the role or user assignment last changed, and STMS or the transport log to see whether a role transport landed in production around the failure timestamp. Finally, check SM21 for lock or password events on the same day if the authorisation angle turns out to be a login problem instead.

Pull SM37 job logs for the affected job name filtered by cancelled status over the relevant date range, and line them up against the SU01 change history for the job step user and the PFCG transport log for any role that carries an object relevant to that job. The authorisation trace output naming the exact object, field, and value that failed the check, timestamped against the transport or role-change date, is what turns 'the job broke' into a specific, fixable gap.

If the trace points to a missing or narrowed value in an existing role, the fix is a PFCG change: add the object or extend the value range, then transport it through the landscape properly rather than editing the production role directly, since that edit will be overwritten or flagged in the next role comparison. If the job step user is locked or its password expired, unlock it in SU01 as an immediate data fix, then separately decide whether that user should be reclassified to a type that does not expire, which is a config decision for the security team, not an emergency patch. If a new org-level value entered scope, extend the role's authorisation for that value through the normal role change and transport cycle; do not authorise 'all values' as a shortcut. If the RFC or trusted-system side is the actual gap, the fix belongs to whoever owns the target system's role for the trusted user, and needs coordinating across systems. If the buffer is overflowing, the structural fix is reducing the number of roles combined for that user or splitting composite roles, which is a bigger change and should only be pursued once the trace has actually confirmed a buffer-related cause rather than a straightforward missing object.

The first reflex is assigning SAP_ALL, a broad administrative profile, or an oversized composite role to the job step user just to get the run through the night. It works immediately, which is exactly the problem: nobody goes back to identify the one object that was actually missing, so the real gap is masked rather than closed, and the next audit or access review flags the over-provisioned service user as a finding that then has to be unwound, at which point the original job breaks again with the same unexplained error.

The fix sits with the Basis or security administration team, since it is a role and user-master change. The functional module team that owns the job's program should confirm which authorisation object the report genuinely needs, so the fix is precise rather than over-broad. The handover note should record the job name, the step user, the exact object and value that failed, the transport or change that caused it, and whether an emergency direct assignment was made that still needs replacing with a proper transported fix.