Our analytics reporting OData service started returning empty datasets after we modified user roles last week. The strange thing is there are no gateway errors in the logs, and administrator accounts are completely unaffected - they still see all data.
The role change involved adding a new authorization object to restrict data visibility by company code. Regular users now get empty results when querying the same OData endpoints that worked previously. We’ve verified the OData service itself is running and responding with 200 OK status codes, but the result set is empty.
Administrator accounts with SAP_ALL authorization continue to retrieve full datasets without issues. Gateway logs show successful authentication and no authorization failures. What could cause this selective data visibility problem after role modifications?
Your issue is a classic authorization data filtering scenario that occurs when CDS views with Data Control Language interact with newly added authorization objects. Let me break down what’s happening and how to resolve it comprehensively.
Understanding the Role Change Impact:
When you added the authorization object for company code restriction, you introduced a new authorization check that the CDS view’s DCL definition enforces. The fact that there are no gateway errors is actually expected behavior - the OData service authenticates successfully and executes the query, but the DCL applies authorization-based filtering at the database level before returning results. This is why you see 200 OK responses with empty datasets rather than 403 Forbidden errors.
Why Admin Accounts Are Unaffected:
Administrator accounts with SAP_ALL authorization bypass DCL filtering because SAP_ALL provides unrestricted access to all authorization objects, including F_BKPF_BUK. The DCL recognizes this and doesn’t apply company code filtering for these privileged users. Regular users, however, are subject to the DCL’s WHERE clause conditions based on their specific authorizations.
Root Cause Analysis:
Your analytics report’s CDS view has an associated DCL definition that likely contains logic similar to:
ACCESS CONTROL WHERE
CompanyCode = ASPECT pfcg_auth(
F_BKPF_BUK, BUKRS, ACTVT='03'
)
This DCL clause filters the dataset to only include records where the CompanyCode field matches values the user is authorized for via F_BKPF_BUK. When you added this authorization object to roles without populating specific company code values in the BUKRS field, the DCL filtering returns zero records because there’s no match between data and authorization.
Complete Solution:
Verify Current Authorization State:
Have affected users run the report and immediately check SU53
Look for F_BKPF_BUK with missing BUKRS values
Document which company codes each user role should access
Update Role Authorizations:
Use transaction PFCG to edit affected roles
Navigate to the Authorization tab
Locate F_BKPF_BUK authorization object
In the BUKRS field, maintain specific company codes (e.g., ‘1000’, ‘2000’) or use wildcards (‘*’) for all company codes
Set ACTVT (Activity) to ‘03’ for display authorization
Generate and save the role
Refresh User Authorizations:
Run transaction SU10 for mass user changes
Select affected users and use ‘Roles’ tab
Re-assign the modified roles to refresh authorization buffer
Alternatively, users can log out and back in
Validate DCL Logic:
Review your CDS view’s DCL definition in Eclipse/ADT
Ensure the ASPECT pfcg_auth clause correctly references F_BKPF_BUK
Consider adding fallback logic if certain user groups need unrestricted access
Test Systematically:
Test with a single user account first
Verify OData service returns expected company code data
Expand to user groups once confirmed working
Alternative Approach for Broad Access:
If users should see data across all company codes, you have two options:
Set BUKRS to ‘*’ in the authorization object (grants access to all)
Modify the DCL to make company code filtering optional based on a different authorization object
The empty dataset issue will resolve once user roles contain appropriate company code authorizations in F_BKPF_BUK. The authorization check happens silently at the database level, which is why you see successful OData responses with no data rather than explicit authorization errors.
This draft is based on general SAP S/4HANA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
This sounds like an authorization check issue at the data retrieval level rather than the service level. When you added the authorization object for company code restriction, did you also update the CDS view or ABAP query that feeds the OData service? The gateway won’t show errors because authentication succeeds, but the underlying data query might be filtering out all records based on the new authorization checks.
I agree with Tom. The fact that admins see data while regular users don’t, with no gateway errors, points to authorization checks happening during data selection. Check if your analytics report uses a CDS view with DCL (Data Control Language) annotations. When you modified the role, the DCL might now be filtering out all records because users lack the specific company code authorizations. The OData service returns successfully but with zero records because the authorization filtering happens at the database level.
That makes sense. We do use a CDS view for this report. I checked and there is a DCL definition associated with it. The authorization object we added is F_BKPF_BUK for company code. Should I be looking at the DCL definition to see how it’s filtering data based on this object?
Yes, check your DCL definition. The DCL likely has an ACCESSCONTROL clause that references F_BKPF_BUK. When you added this authorization object to user roles, the DCL started enforcing it. If users don’t have specific company codes maintained in their role authorizations, the WHERE clause in the DCL filters out all records. You need to either update user roles with appropriate company code values or modify the DCL logic to handle cases where users should see data across multiple company codes.
Quick way to verify: use transaction SU53 immediately after a user gets empty results. This shows the last failed authorization check. If F_BKPF_BUK appears with missing company code values, that confirms the DCL is filtering based on authorization data. The solution is to maintain company code authorizations in user roles. Make sure you’re adding company codes to the BUKRS field in the F_BKPF_BUK authorization object within each affected role.