SAP HANA Analytic Privileges: A Practical Guide to Row-Level Security

SAP HANA analytic privileges provide row-level security for calculation views and other analytical models. They determine which records a user can see after the user has permission to access the underlying object.

A reliable implementation separates object authorization from data filtering. SQL privileges provide access to a schema object, while an analytic privilege limits the rows returned from an analytical object according to conditions such as company code, region, sales organization, or business unit.

01How analytic privileges work

An analytic privilege evaluates a user's access to an analytical object. The object can be a calculation view or another object that supports analytic authorization. Its definition contains the permitted data scope, such as a fixed list of values or a value supplied through an authorization mechanism.

The authorization check takes place when the user queries the protected object. A user can therefore have access to the same calculation view as another user while receiving a different result set.

A typical access path contains these layers:

1. The user authenticates to the target tenant database.
2. A role grants the required SQL privilege on the analytical object.
3. The role grants the analytic privilege.
4. The query engine evaluates the analytic condition.
5. The result contains only rows inside the permitted scope.

This layered model is useful when investigating access problems. A missing SQL privilege produces an authorization error, while an analytic privilege that evaluates to an empty scope produces no matching rows.

For broader modeling context, see SAP HANA Development Overview, which describes how analytical models fit into HANA development work.

02Analytic privilege versus SQL privilege

SQL privileges authorize actions on database objects. For example, a role may grant SELECT on a calculation view. These privileges answer the question: can the user access this object?

Analytic privileges answer a different question: which data may the user see through this object? They are evaluated as data filters and are especially useful for multi-organizational reporting.

Granting SELECT alone does not define a row-level restriction. The analytical object must also be designed so that the relevant attributes are available for authorization.

The related SAP HANA User Privileges article covers the broader privilege and role model used when assembling these grants.

03Designing a row-level security model

Start with the business access rule rather than with the privilege editor. Document the protected object, the attribute used for filtering, the allowed values, and the identity source that supplies those values.

A practical design record includes:

• Protected object: the calculation view or analytical object exposed to users.
• Security attribute: the column that represents the business boundary.
• Allowed scope: one value, a set of values, or a user-dependent mapping.
• Role assignment: the technical role that carries the analytic privilege.
• Test identities: users representing each expected access pattern.

Keep the security attribute in the analytical model's output and preserve its meaning through joins and projections. If a calculation view removes or transforms the attribute before authorization is evaluated, the intended restriction becomes difficult to implement and test.

For calculation-view modeling details, use SAP HANA Calculation Views as the companion reference. A security design is easier to maintain when the model exposes business dimensions with stable names and clear semantics.

Use separate analytic privileges for materially different policies. For example, a regional reporting role and a company-code reporting role should have independently understandable definitions. This makes change review, testing, and incident analysis more predictable.

04Creating and assigning an analytic privilege

SAP HANA database explorer and SAP HANA cockpit provide administration interfaces for inspecting users, roles, privileges, and database objects. Use the tool that matches your operational workflow and connect to the tenant database containing the analytical object.

A common implementation sequence is:

1. Create or identify the calculation view that requires row-level protection.
2. Define the analytic privilege against that object.
3. Add the permitted attribute values or the user-dependent authorization logic.
4. Activate or save the privilege according to the development workflow.
5. Add the analytic privilege to a role.
6. Grant the role to a test user or user group.
7. Grant the required SQL privilege on the protected object through the same role or a separate role.
8. Test both permitted and restricted data scopes.

In SQL-based deployment workflows, privilege definitions and role grants are managed as database artifacts or SQL statements appropriate to the target object. Keep those artifacts under source control with the calculation-view definition so that the model and its security policy move together.

Use least privilege at each layer. Give the reporting role access to the required object and analytic scope only, and keep administrative privileges in separate operational roles.

05Testing row-level security

Test analytic privileges with dedicated users or controlled role assignments. A test session should represent one complete authorization path, including the tenant connection, SQL privileges, analytic privilege, and role inheritance.

Use a test matrix with at least these cases:

Test direct access to the protected calculation view and access through each consuming application or reporting tool. Application behavior can differ when it uses a technical database user, connection pooling, or delegated identity.

Record the connection user, tenant database, assigned roles, query object, filter values, and result count for each test. This evidence makes later troubleshooting substantially faster.

06Troubleshooting analytic privilege failures

Begin with the authorization path rather than the application screen. Confirm the tenant database, database user, role assignments, SQL privilege, analytic privilege assignment, and protected object in that order.

Authorization error

An authorization error usually points to a missing SQL privilege, an inactive role assignment, an incorrect object reference, or a connection to the wrong tenant database. Check the effective role assignment for the exact user used by the application.

Empty result set

An empty result set usually indicates that the analytic condition excludes the requested records. Check the attribute values, capitalization, data type, join path, and user-dependent mapping. Compare the result with a controlled test user whose permitted scope is known.

Unexpectedly broad access

Broad access requires an immediate review of role inheritance and the analytic privilege definition. Check whether another assigned role grants a wider analytic scope or whether the application uses a technical user with broader permissions than the interactive user.

Authorization works in one tool but not another

Compare the database user, tenant, connection properties, and session context used by SAP HANA database explorer, SAP HANA cockpit, and the application. A successful test in one session proves only that session's authorization path.

For SQLScript-based applications, also review the procedure or table-function design. The consuming object must preserve the intended authorization boundary, and the execution context must match the security design. The SAP HANA SQLScript Procedures article provides related guidance for reviewing procedure-based access paths.

07Operational practices for maintaining privileges

Treat analytic privileges as production security artifacts. Review them during every change to a calculation view, authorization attribute, role hierarchy, or identity mapping.

Recommended controls include:

• Store definitions and role assignments in the project's deployment repository.
• Use descriptive names that identify the protected object and business scope.
• Separate development, test, and production assignments.
• Keep a documented owner for every business access rule.
• Re-test after changing joins, projections, calculated columns, or authorization attributes.
• Review inherited roles when a user reports unexpected access.
• Remove obsolete privileges and role assignments promptly.
• Capture both successful and denied test cases in the release record.

Monitor privilege changes through the database security and change-management processes used by the SAP HANA operations team. A clear ownership model prevents analytic privileges from becoming undocumented filters that only one developer understands.

08Practical implementation checklist

Before releasing a row-level security change, confirm the following:

• The protected analytical object is identified.
• The SQL privilege and analytic privilege are both assigned through an intentional role design.
• The security attribute is present and correctly propagated in the model.
• Allowed and denied values have been tested with representative users.
• The application connection uses the intended tenant and database user.
• Role inheritance has been reviewed for broader access.
• The privilege definition is stored with the related model deployment artifacts.
• A rollback or removal procedure is documented.

Analytic privileges are most effective when they are designed with the calculation view, deployed with the application, and tested as part of the complete authorization path. This approach gives SAP HANA row-level security a clear operational boundary and makes access behavior explainable during support work.