<aside> 🔒

This section explains how to implement Row-Level Security (RLS) in Sigma in conjunction with embedding through MyReportPortal.

</aside>

I. Executive Summary

Embedded analytics has a compelling value proposition for many organizations: by giving customers, partners, or vendors direct access to data within your own portal, you drive product value, increase stickiness, and empower your users. However, the hidden challenge lies in the execution. You cannot simply expose a dashboard; you must ensure that Customer A never views Customer B’s sensitive data. This security pattern is called Row-Level Security (RLS).

At MyReportPortal, we believe implementing RLS in Sigma Computing is incredibly powerful, but it requires a solid data foundation. This white paper bridges the gap between high-level security requirements and technical implementation, showing you how to build a robust architecture that makes embedding Sigma easy.

II. Mapping the "Embed User" to the Data

The most common friction point in RLS is the "Identity Disconnect." Many technical guides operate under the assumption that your transactional tables already contain a user_email column. In reality, they rarely do.

To succeed, you must first define your entities:

• The Application User: The individual logging into MyReportPortal, typically identified by a unique email or User ID.
• The Business Entity: The customer, tenant, vendor, or region they are associated with (e.g., Account_ID, Supplier_Code).
• The Transactional Data: The raw data (sales, logs, inventory) you intend to display.

Your mission is to trace the data lineage from the Application User to the Transactional Data, creating a clear map that the system can query dynamically.

III. Designing the RLS Relationship Matrix

Visualizing the flow from: User Table → Entitlements Table → Sales Table.

Scenario A: The Direct Relationship (1:1 or 1:Many)

When the application user is directly employed by a specific client, the logic is straightforward. If the sales table contains a vendor_id, you simply need a lookup map to find the Vendor ID associated with the User Email..

Scenario B: The Indirect/Bridge Relationship (Complex Hierarchy)

If a regional manager oversees multiple franchises, or a consultant works across several accounts, you need an "Entitlements" or "Bridge" table in your data warehouse. This table maps a single User Email to multiple Entity IDs, allowing for complex, many-to-many permissions without code bloat.