Sharing a report
The Share button works like any Google Doc: invite individuals, share with a domain, or make it link-accessible. Roles are Viewer and Editor.
Sharing the report is only half of it, though — access to the underlying data is controlled separately, and that is where mistakes happen.
Owner versus viewer credentials
Each data source uses either owner's credentials or viewer's credentials.
Owner's credentials means everyone sees the data through your access. Anyone who can open the report sees everything you can see, whether or not they have rights to the source.
Viewer's credentials means each person authenticates themselves and sees only what they are permitted to.
Owner's credentials is the default because it is convenient — the report works for everyone with no setup. It is also how confidential data ends up in front of people who should not have it.
For anything sensitive, use viewer's credentials and let the source system enforce access.
Row-level control
Looker Studio has no built-in row-level security. The usual approaches are filtering by the viewer's email with the @DS_USER_EMAIL parameter against a mapping table, or enforcing it upstream in BigQuery with authorised views.
Upstream is the more robust option — a filter in a report can be removed by anyone with edit access.
Scheduled delivery
Share → Schedule email delivery sends a PDF on a schedule to a list of recipients.
Worth knowing that it renders the report with its default filter state, not whatever anyone last selected. Set sensible defaults before scheduling, or people receive a PDF filtered to something arbitrary.
Embedding
Share → Embed report gives an iframe snippet or an embed URL for a website or intranet.
Embedded reports still respect permissions: unless the report is link-accessible, visitors need access. If you embed on a public site, the report is public — and so, with owner's credentials, is the data behind it.