ERPClimb logoERPClimb
Login
SAP authorization objectObjectS_QUERYModuleSECURITY_GRC

S_QUERY — S_QUERY Authorization Object for SAP Query

S_QUERY controls what a user may do inside the SAP Query environment (SQ01, SQ02, SQ03, and the Quickviewer SQVI) - create, change, display, delete, execute, or transport a query. It checks only an activity code, not a specific query name, so it always works alongside S_USER_GRP, which restricts which query user groups the user can even see.

This page covers the S_QUERY authorization object used by the SAP Query tool set, the single activity field it checks, and why failures are so often misattributed to it when the real blocker is the paired user-group object. It also walks through the practical trace sequence for a query authorization failure and the recurring design mistakes that make roles look correct on paper but fail in the query transactions.

Reviewed by an ERPClimb SAP consultant on 16 Sept 2026· 961 words

What it protects

S_QUERY guards the activities available in the ABAP Query tool set: creating, changing, displaying, deleting, executing, and transporting queries, InfoSets, and functional areas from SQ01, SQ02, SQ03, and the Quickviewer SQVI. The structural fact that explains most of the confusion around it is that S_QUERY is activity-based only - it never names a specific query, InfoSet, or functional area. Authorization is granted at the level of 'this user may execute activity X in the query tool' and is combined with a completely separate object, S_USER_GRP, which decides which user groups the person can work in at all. A user can pass S_QUERY cleanly and still be denied outright because the user group check fails first, or the reverse. Treating the two objects as one check is the single most common source of wasted troubleshooting time on this object.

Fields checked

  • ACTVT - the activity being attempted inside the query tool; typical values include 01 (create), 02 (change), 03 (display), 06 (delete), 16 (execute), and 23 (transport). This is the only field carried on S_QUERY - there is no field for query name, InfoSet name, or functional area, which is why the object cannot restrict access to one specific query. Fine-grained scoping by user group is delegated entirely to S_USER_GRP, and scoping by which fields or tables an InfoSet may read is delegated to the data-source authorizations built into the InfoSet itself, not to S_QUERY.

Where it is checked

  • SQ03 - maintaining query user groups; checks S_QUERY with activity 01/02/03/06 depending on what is being done to the user group assignment itself.
  • SQ02 - maintaining InfoSets; checks S_QUERY at the point a new InfoSet is generated or an existing one is changed or displayed.
  • SQ01 - maintaining and running queries; checks S_QUERY for create/change/display/delete when the query definition is touched, and separately for activity 16 the moment 'Execute' is pressed.
  • SQVI (Quickviewer) - runs on the same underlying query engine and triggers the same S_QUERY check even though the transaction code is different, which surprises people who lock down SQ01 and assume the tool set is closed.
  • Transport of queries out of SQ01's environment menu, or via the standalone query transport transaction, checks activity 23 in addition to the create/change activity already used to build the query.

How to trace a failed check

Start with SU53 immediately after the failed action, before doing anything else in the session, since SU53 only shows the last failed check and a second failed action overwrites it. If SU53 shows S_USER_GRP rather than S_QUERY, stop chasing S_QUERY entirely - the user group assignment is the actual problem. If SU53 is empty or the check happened in an earlier step of a chained action such as generate-then-execute, switch to the authorization trace (ST01 or the newer STAUTHTRACE) started before reproducing the issue, then filter the trace output for object S_QUERY and S_USER_GRP together, since both fire in the same flow. Capture the full trace line - object, field, value requested, value held, and return code - along with the transaction code, the query name and user group involved, and the exact button or menu path pressed. Hand the security team that trace extract plus the reproduction steps rather than a description of the symptom; a request that just says 'cannot run query' forces them to re-run the trace themselves.

Whose problem this is

This is a shared problem. The functional or reporting team identifies which activity and which user group are involved and reproduces the failure with a trace; the security team decides whether to extend the existing role or build a new one, since S_QUERY activity 02 is broad and its risk has to be weighed against segregation-of-duties rules. A good request states the transaction, the activity attempted, the query user group, and the trace extract - not just 'give me access to queries'.

Common pitfalls

  • A role grants S_QUERY with activity 02 (change) but the user is not assigned to the query's user group in S_USER_GRP - the failure looks like a query authorization problem but the real fix is a user group assignment, not a change to S_QUERY.
  • Activity 23 (transport) is left out of the role because the person who built it only tested query creation in the development client - the query works fine until someone tries to move it forward, and by then the request looks unrelated to the original role design.
  • Because S_QUERY has no query-name field, granting activity 02 to 'let one user fix one broken query' actually grants change access to every query in every user group that user can reach through S_USER_GRP - a much wider grant than intended and a common audit finding.
  • SQVI is overlooked when locking down the query tool set, because attention focuses on restricting the SQ01/SQ02/SQ03 transaction codes and the fact that Quickviewer runs through the identical S_QUERY check is missed.
  • A failed check is read as 'the user has no query authorization at all' when in fact they have every activity except the one attempted - display works, change does not - because the role was built activity-by-activity and one was never added.

Related SAP objects

Reviewed pages this object connects to in the ERPClimb knowledge graph.

Source: ERPClimb — https://erpclimb.com/sap-auth-objects/s-queryERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.