View the original community article here
Last tested: Oct 1, 2018
There are three parameters in an embed URL that can be populated to set the features within Looker that a user has access to:
| ||No||The list of Looker groups the user should be a member of, if any. Use group IDs instead of group names.||Array of integers|| |
| ||Yes||The list of permissions the user should have. |
See the permissions section for the list of allowed permissions.
|Array of strings|| |
| ||Yes||The list of model names the user should have access to.||Array of strings|| |
models parameters create a role for the embed user (this will show up as "Embedded Role" in the Admin - Users panel). If permissions/models are explicitly stated in the embed URL, and the
group_ids parameter is also specified, then the Embedded Role will be ADDITIVE with any roles that are assigned to the listed groups in the
group_ids parameter (the same way that all roles in Looker are additive).
An embedded URL is created with a user that has the following stated in the URL:
group_ids parameter =
 --> Group ID 1 in Looker is associated with a role that has the
explore permission on
permissions parameter =
["access_data","see_looks"] --> View Only User
models parameter =
The user has the ability to view and explore the data on
model_one, but only the ability to view the data on
While a company may use Roles associated with
group_ids to assign embed user permissions as well as explicitly stated in the SSO script, it may introduce confusion as info about embed users would be then be stored both in Looker and in the parent application. It will be easier to manage if embed user info all lives in one place—outside the looker application stated in the Embed URL script only. However, some may elect to leave the
models parameters blank and control roles exclusively through role-group assignments if the admin users who manage roles for their embed users do not have access to their embed URL generation script.