S_SPO_DEV — Authorization for selecting a spool output device
S_SPO_DEV controls which spool output devices (printers) a user is allowed to select and output to when printing or generating spool requests. It does not control what a user can do to spool requests already sitting in the spool queue - that is a separate object. Failures show up as a print dialog that rejects the chosen device, not as a missing transaction.
This page covers the S_SPO_DEV authorization object, which restricts which output devices a user can select during printing or spool creation. It explains the fields checked, where the check fires in the print flow, how to trace a rejection with SU53 and the authorization trace, and the common confusion with the object that governs actions on existing spool requests.
Reviewed by an ERPClimb SAP consultant on 16 Sept 2026· 846 words
What it protects
S_SPO_DEV guards the moment a user picks an output device - a printer, a fax device, or a logical spool device - when creating output, whether interactively from a print dialog or through a background job that routes its spool to a device. The structural fact that causes most confusion is that this object only fires when a device is actually selected for output; it says nothing about whether the user can view, delete, or reprint a spool request that already exists. Two separate objects govern the same spool subsystem from two different angles: one restricts which devices can be targeted, the other restricts what can be done to requests once they are in the queue. Consultants who see a spool-related authorization failure often assume it is this object without checking which of the two is actually in the SU53 trace.
Fields checked
- SPODEVICE - the name of the output device (printer or logical device) the user is trying to select; can be restricted to specific device names or opened with a wildcard for print pools shared across a plant or site
- ACTVT - the activity being performed against the device, typically output/print, display, change or delete, depending on whether the check fires during printing, device inquiry, or spool administration touching that device
Where it is checked
- Interactive print dialogs, at the moment the user selects or confirms the output device before the spool request is created
- Background job scheduling when a step defines a print parameter pointing to a specific device, checked at job release or at the point the job actually writes spool output
- SP01 and SP02 spool control screens when a user filters or restricts the list by device rather than by spool request owner
- Programs that generate mass output (batch printing, forms, correspondence runs) where the device is set programmatically rather than chosen from a dialog
- Device maintenance activity in spool administration transactions, where changing or deleting a device definition itself is also gated by this object in some system configurations
How to trace a failed check
Reproduce the failure and immediately run SU53 for the affected user; it captures the specific SPODEVICE value and ACTVT that failed at the moment of the print attempt, which is the single most useful piece of evidence here because the device name tells the security team exactly which authorization value is missing. If the failure happened inside a background job, SU53 after the fact is often empty because the job ran under a different session context, so pull the job log and check whether the step failed with a spool-related short dump, then run the authorization trace transaction for the job user around the execution window. Confirm the failing object is S_SPO_DEV and not the object governing spool request actions - the field names differ and this distinguishes a device-selection problem from a spool-viewing problem. Hand the security team the user id, the exact device name from the trace, the ACTVT value, and whether the attempt was interactive or via a background job.
Whose problem this is
This is a security team build item, but functional or basis input is needed to define which devices belong to which authorization group or naming pattern, since device names vary by site and print landscape. A good request names the device or device naming pattern, the activity needed (usually output only, rarely delete or change), and whether the requirement is for interactive printing, batch job output, or both.
Common pitfalls
- A role grants S_SPO_DEV with the right devices but missing the ACTVT value the transaction actually checks, because different print paths request different activities for the same device
- The failure is diagnosed against S_SPO_DEV when the actual missing authorization is the object controlling actions on spool requests already in the queue, since both surface as generic print errors to the end user
- Devices are added to the print landscape without updating the authorization values or naming convention behind them, so a role that worked for months suddenly fails after a new printer is rolled out under a name outside the existing pattern
- Background job output fails silently into the job log rather than throwing a visible authorization popup, so the missing authorization is misreported as a technical spool error rather than a security gap
- Wildcarding SPODEVICE broadly to make a printing problem go away, which removes the ability to control who can route sensitive output (payroll forms, financial statements) to shared or unattended devices
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/s-spo-devERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.