S_SPO_ACT — Authorization for Spool Request Actions
S_SPO_ACT controls actions performed on spool requests belonging to another user or client, such as display, delete, output again, or forward to another device. It is checked from SP01, SP02, and background job spool buttons whenever the target spool request is not the calling user's own. A user's own spool output generally bypasses the check entirely, which is why the object's failures rarely appear in isolated testing.
This page covers what S_SPO_ACT governs, the fields SAP checks against it, and where in the spool workflow the check actually fires. It focuses on the diagnostic sequence for a failed check, because the object's behaviour around ownership of spool requests is the source of most confusion.
Reviewed by an ERPClimb SAP consultant on 16 Sept 2026· 916 words
What it protects
S_SPO_ACT protects actions taken against a spool request: displaying its content, deleting it, printing it again, or redirecting it to a different output device. The action is reached from SP01, from SP02's extended list, or from any transaction's print preview that lets a user act on spool output belonging to someone else. The structural fact that drives almost every support ticket on this object is that a user's own spool requests are, in most cases, not subject to this check at all; ownership alone grants access. The check only engages when the requesting user id differs from the owning user id stored on the spool request. That is why a report tested by its author works cleanly, but the same report run as a background job under a batch user, or accessed later by a different support agent, fails on an action that the original tester never had reason to attempt.
Fields checked
The object carries a single meaningful field in normal use.
- SPOACTION - the specific action being attempted against the spool request: displaying its content, deleting it, releasing or printing it again, or forwarding it to another output device. Each call checks one action value at a time, not a combined set, so a role granted 'display' will still fail on 'delete' even for the same spool request.
Where it is checked
The check is called at the moment a user selects an action on a spool entry that is not their own, rather than when the spool list itself is displayed.
- SP01 - full spool request overview, checked when a user attempts display, delete, or resend on an entry owned by another user id
- SP02 - the user's own spool request list; normally does not trigger the check because entries are self-owned, unless the list is switched to show all requests
- SM37 job spool button - checked when a support user opens the spool output of a batch job whose steps ran under a different technical or batch user id
- Print preview and output dialogs reached from application transactions, when the user tries to re-issue or delete an existing spool entry rather than create a new one
- Custom or standard programs (RSPO* family and similar) that manipulate spool requests programmatically on behalf of a user other than the caller
How to trace a failed check
Start with SU53 run immediately after the failed action, before anyone else's activity overwrites the buffer; look for S_SPO_ACT with the SPOACTION value that was attempted, and note whether the field shows as missing entirely or present with the wrong value. If SU53 shows nothing relevant, which happens when the failing call runs in a background work process, batch job step, or RFC context rather than the user's own dialog session, switch to the full authorization trace and filter it on S_SPO_ACT before reproducing the action. Capture the spool request number, its owner (visible in SP01's owner column), the user id that attempted the action, and the exact action (display, delete, resend, forward). Hand the security team that combination rather than a general complaint about 'cannot access spool'; the owner-versus-requester mismatch is usually the actual root cause, and the trace extract confirms whether it is an authorization gap or something else, such as a locked spool request.
Whose problem this is
This is a security team fix once the functional side has identified the failing action and confirmed the ownership mismatch. A good request states the user id, the spool request number and its owner, the exact action attempted (display, delete, resend, forward), the transaction or program used, and the SU53 or trace extract. Security adds the missing SPOACTION value to the relevant role rather than granting the object blanket.
Common pitfalls
Most confusion comes from testing that never exercises the ownership boundary the object actually protects.
- A role tests fine because the tester only ever acted on their own spool requests, which bypass the check regardless of what SPOACTION values the role contains
- S_SPO_ACT gets confused with S_SPO_DEV; the former governs the action on the request, the latter governs which output device the request can use, and a failure on one is often misdiagnosed as the other
- Background jobs run under a batch or technical user id, so the spool output is owned by that id, not by the person who scheduled the job; a support agent opening that spool from SM37 needs the action authorized for requests they do not own, which their personal role may never have needed before
- Shared or collected spool output from mass batch runs is owned by the scheduling user for every step, so authorizing one user for their own spool does nothing for colleagues who need to review the same output
- A failed delete or resend is sometimes read as a locked or expired spool request rather than a missing action authorization; checking SU53 before assuming the request itself is broken avoids wasted troubleshooting
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/s-spo-actERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.