Based on the data security needs for this project described in Chapter 1, Planning Power BI Projects, it's not necessary to retrieve any tables for the purpose of implementing a row-level security (RLS) role. As shown in the Sample Power BI project template section in Chapter 1, Planning Power BI Projects, the sales managers and associates should only have access to their Sales Territory groups, while the Vice Presidents should have global access. With these simple requirements, the security groups of users (for example, North America, Europe, the Pacific region) can be created and assigned to corresponding RLS roles defined in the data model. See Chapter 4, Developing DAX Measures and Security Roles, for details on implementing these security roles.

In projects with more complex or granular security requirements, it's often necessary to load additional tables to the data model such as a Users table and a Permissions table. For example, if users were to be restricted to specific postal codes rather than sales territory groups, a dynamic, table-driven approach that applies filters based on the user issuing the report request would be preferable to creating (and maintaining) a high volume of distinct RLS roles and security groups. Given the importance of dynamic (user-based) security, particularly for large-scale datasets, detailed examples of implementing dynamic security for both import and DirectQuery datasets are included in Chapter 4, Developing DAX Measures and Security Roles.