[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-07-31 (世界標準時間)。"],[],[],null,["# Best practice: Manage users with groups\n\n\u003e *These best practices reflect recommendations shared by a cross-functional team of seasoned Lookers. These insights come from years of experience working with Looker customers from implementation to long-term success. The practices are written to work for most users and situations, but you should use your best judgment when implementing.*\n\n\nManaging users properly is crucial to ensuring that only the appropriate people have access to particular data, features, and content within Looker. Unless you have a completely [open system](/looker/docs/access-levels#configuring_a_completely_open_system), it will be important to implement a strategy for managing users that ensures that all data and content is secured. Using groups will help with this and can prevent the need to add, manage, and update user access at the individual user level.\n\nMap out permissions\n-------------------\n\n\nBegin by making a high-level plan and mapping out the permissions and access that will be required across your user base.\n\n- Identify the different datasets available within Looker and the combinations of these that should be available to different user groups. If your organization has only one model, this is easy. If your organization has several models, there may be a few different combinations of models ([model sets](/looker/docs/admin-panel-users-roles#model_sets)) that need to be created.\n- Identify the different user types that you have. Common users include people who can view dashboards but not explore data, people who can explore data but not write LookML, people who can write LookML, and administrators. The features that each of these user types will be able to use should be set up using [permission sets](/looker/docs/admin-panel-users-roles#permission_sets).\n- Think about how the data access (model sets) and feature access (permission sets) intersect. For example, there may be a large number of users whose data access is restricted to a single model and whose feature access is restricted to dashboards. This data and feature access would be combined to create a role.\n\nMap out groups\n--------------\n\n\nNext, think about the functional groups within your user base, such as Sales, Finance, etc. These functional groups should be reflected in the [groups](/looker/docs/admin-panel-users-groups) you can assign users to within Looker. Groups can be used to secure content (dashboards and Looks).\n\n- For example, you might have a Sales department in your organization, and inside of that department there may be several account executives alongside a small Sales Operations team. You could create a Sales group in Looker, and then inside of the Sales group create one subgroup for Account Executives and another subgroup for Sales Ops. The Account Executives group might map to a role with viewer permissions, and the Sales Ops group might map to a role with explorer permissions.\n- Access to folders --- and therefore to content --- can be [managed using these groups](/looker/docs/organizing-spaces#viewing_and_managing_folder_access_levels). For example, within the **Shared** folder you could create a **Sales** folder that only the Sales department can see. Members of the Account Executives group could be given View access to that folder, while the Sales Ops team might have the ability to manage access to that folder and edit content within it.\n- Changes to access or permissions for the entire Sales department can be managed using the Sales group.\n- Changes to access or permissions for either the Account Executives or the Sales Ops team can be managed at the subgroup level.\n- New users can be added to the appropriate group and will automatically inherit the appropriate permissions.\n\nApply controls at the group level\n---------------------------------\n\nAs you begin to apply controls at the group level, keep the following tips in mind:\n\n\u003cbr /\u003e\n\n- When setting up users, do not give any roles directly to the user. Simply assign each user to a group. Users given individual roles and roles based on group membership will *inherit all roles from both the individual and group assignments*.\n- Take care when placing users in multiple groups. Users in multiple groups get the sum of *all* privileges of all the groups they're in, so ensure that users in multiple groups are still limited to the appropriate level of access.\n- When possible, assign user attribute values at the group level.\n\n\nTo see these practices applied, refer to the Best Practices page on setting up secure content access --- [Best practice: Secure your spaces! A content access walk-through](/looker/docs/best-practices/how-to-secure-your-folders)."]]
