Atlas Fleet: Partner Row-Level Security and a PDF Request
Atlas Fleet is a logistics SaaS provider with 18 channel partners. Partner users need to see shipment volume and on-time performance only for accounts assigned to their partner. The warehouse has shipments at one row per shipment, accounts at one row per account, and partner_account_map mapping partner_id to account_id; an account belongs to one partner. There are 3,000 accounts and 420 external users. Internal account managers need to see all partners. Atlas plans to embed Looker dashboards in its partner portal using SSO. The security team asks for a design before the pilot. A partner has also requested a PDF of the dashboard every Monday. The current Explore has no row-level restriction, and the dashboard has a 'Partner' filter that users can change.
1. Design row-level access control for partner users and internal account managers. Specify where the restriction belongs and how to avoid relying on the dashboard filter.
Read the worked answer
Enforce access in the model, not in the dashboard. Create a dedicated partner model and Explore that joins partner_account_map into the shipment facts. Add an access_filter on the partner field, using a user attribute such as partner_id populated from SSO at embed login:
access_filter: {
field: partner_account_map.partner_id
user_attribute: partner_id
}
Because this filter is applied to every query in that Explore, a partner cannot remove it by changing a dashboard filter. Remove or make read-only the visible 'Partner' filter; it should never be the security boundary. For internal account managers, use a separate internal model and Explore without the access filter, assigned through a model set and group. If you must use one Explore, a Liquid sql_always_where can branch on a user attribute value such as ALL, but that is easier to misconfigure; separate models are clearer. Test with two partner users and one internal user, and verify that scheduled, embedded, and downloaded results all respect the restriction.
2. Evaluate the PDF request. What are the risks, and what alternative would you propose if the partner still needs a scheduled view?
Read the worked answer
A PDF schedule breaks the row-level security model after delivery. The file contains a static snapshot, can be forwarded to anyone, cannot be re-authenticated, and cannot be revoked when a partner employee leaves. Once it leaves Looker, the partner filter in the dashboard no longer protects anything. If the partner needs a Monday view, the better option is an authenticated embed in the partner portal, using SSO and the same user attribute, so each viewer sees only their data and access can be revoked. If the partner requires a file, deliver it through a controlled channel that re-authenticates the recipient or use a partner-specific schedule to a destination the partner owns, with a clear data-sharing agreement. Disable external schedules and downloads for the partner group by default, and allow exceptions only after security review. For internal account managers, PDF schedules may be acceptable because they already have broad access. The decision should be based on data sensitivity and recipient identity, not on convenience.
3. What governance checks and content settings should be in place before the external pilot launches?
Read the worked answer
Before the pilot, confirm four things: identity, authorization, content, and monitoring. Identity: embed SSO passes a verified partner_id user attribute and rejects users without one. Authorization: external users get a least-privilege role, a partner-specific model set, and no Explore creation or SQL access. Content: only validated dashboards go into the partner folder; remove unused fields, hide sensitive dimensions, and verify that every tile respects the same access filter. Disable downloads, schedules, and external email for the partner group unless explicitly approved. Monitoring: enable audit logs, review System Activity for unusual queries, and assign an internal owner for partner access incidents. Test with a pilot partner that has a small account set, then attempt to access another partner's account and confirm the result is empty. Also prepare a data-sharing agreement and an offboarding process so access is removed when a partner user leaves. Re-run content validation after every LookML deployment that affects the partner model.