S_ARCHIVE — Authorization Object for Archiving Actions
S_ARCHIVE controls who can write, read, or delete data through the SAP Archive Development Kit, typically from transaction SARA. It checks the activity (write, read, delete, reload) against a specific archiving object such as FI_DOCUMNT or MM_MATBEL. It does not control access to the archived business content itself, only the archiving action.
This page covers what S_ARCHIVE actually restricts inside the ADK archiving framework, the fields it checks, where in SARA and related batch jobs the check fires, and how to isolate an archiving authorization failure that does not surface through SU53 because it happens inside a background job. It also flags the recurring mistake of treating S_ARCHIVE as sufficient to view archived documents.
Reviewed by an ERPClimb SAP consultant on 16 Sept 2026· 841 words
What it protects
S_ARCHIVE guards the archiving actions performed through the Archive Development Kit: writing data to an archive file, reading it back, deleting it from the database after a successful write, and reloading it. It is checked per archiving object, meaning the technical name assigned to a specific data set type in a module, such as an FI document archive or an MM material document archive. The structural fact that causes most confusion is that this object protects the archiving process, not the underlying business document. Having S_ARCHIVE authorization to read an archive does not grant authorization to display the business object once it is retrieved from the archive; that check still runs against the application's own authorization objects. Consultants who conflate the two spend time widening the wrong role.
Fields checked
- ACTVT - the activity being attempted: 01 for write/create the archive file, 03 for display/read, 06 for delete after archiving, and in some configurations a reload activity. Each phase of an archiving run checks a different value, so a role scoped to read only will fail during the delete phase.
- ARCHIV_OBJ (technical archiving object name, for example FI_DOCUMNT or SD_VBRK) - restricts which archiving object the write, read, or delete action applies to. A role authorized for one archiving object does not cover another even if both belong to the same module.
Where it is checked
- SARA (Archive Administration) - checked at the point a write, delete, read, or reload job is scheduled or started for a given archiving object, before the job step actually runs.
- The ADK job programs themselves (the write, delete, and read programs generated per archiving object) - checked again at job runtime under the job step user, independently of who scheduled the job in SARA.
- Reload and retrieval programs that pull archived data back into the database or into a display for reporting - checked before the reload proceeds.
- Some application transactions that trigger on-the-fly archive reads (for example displaying an already-archived accounting document) - checked at the moment the application asks the ADK to fetch the archived record, before the document content authorization check runs.
How to trace a failed check
Start with SU53 immediately after the failure, but treat an empty or unhelpful result as expected rather than conclusive: archiving jobs run as background jobs under a job step user, and SU53 for the person who scheduled the job in SARA will show nothing because the actual failure happened in a different user context. Pull the job log for the archiving run and look for the return code and the authorization error message, which names the object and the missing activity. If the job log is inconclusive, run an authorization trace (ST01, or STAUTHTRACE on newer systems) against the job step user while the archiving program is rerun in test mode, then filter the trace for S_ARCHIVE. Hand security the job step user ID (not the scheduling user), the archiving object technical name, the activity code from the trace or job log, and the program or transaction that triggered it.
Whose problem this is
Archiving authorization is usually split: security maintains the S_ARCHIVE role content, basis administers the job scheduling and job step users, and the functional consultant identifies which archiving object and phase the process needs. A useful request to security names the job step user, the archiving object technical name, the activity (write, read, or delete), and whether the need is a one-off cleanup or a recurring scheduled job.
Common pitfalls
- A role with S_ARCHIVE granted for read only passes the write phase test but fails on delete, because archiving runs in phases and each phase checks a different activity value.
- The scheduling user in SARA has full access, but the job actually executes under the job step user configured for background processing, and that user's role is the one that needs S_ARCHIVE, not the scheduler's.
- A role authorized for one archiving object is assumed to cover 'archiving in general' and is not extended when a new archiving object is introduced for a different module, producing the same error again under a new object name.
- Reading an archived document successfully through S_ARCHIVE is mistaken for full access to that document, when the application's own document-display authorization object still applies and can independently block the user.
- Failures inside background jobs are chased through SU53 on the wrong user session, wasting time before anyone checks the job log or reruns a trace against the correct job step user.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/s-archiveERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.