Ä¢¹½Av

Every Power BI user gets a personal workspace called My Workspace. This space is ideal for working on projects alone, such as developing, testing, or exploring content. However, it’s not meant for sharing or production use. For collaboration or sharing reports, users should use shared workspaces. These workspaces enable controlled access, improved version management, and publishing content through Power BI apps.

Access to the workspace should be configured according to the following guidelines:

• Admin - Teams should appoint one or more members as workspace administrators. Workspace administrators can update settings, manage access, and create apps.

• Member - Workspace administrators can designate other team members as members. Members can add additional users to the workspace with fewer permissions (i.e., contributors and viewers).

• Contributors - Contributors added to the workspace can develop or modify content, but they cannot change workspace access.

• Viewers - Do not use the Viewer role to share content with external users. Instead, users should access the content through an .

Snowflake is the preferred data lake. When discussing enterprise data sources, we will focus on Snowflake. However, you can also get data from other sources, such as SQL databases, CSV files, and existing Power BI models.

To connect to Snowflake from Power BI Desktop:

1. Select Get Data > More… from the toolbar.
2. Search for Snowflake in the Get Data window.
3. Select it, and click Connect.
4. Enter the following information in the Snowflake window:
   • Server: cmu-data.snowflakecomputing.com
   • Warehouse: powerbi
5. Click OK.
6. (Optional) Use Advanced options to query your database using SQL if you prefer.
7. When prompted to authenticate, do one of the following:
   • Log In with your Andrew account - select Microsoft Account, click Sign In, and Connect.
   • Use KeyPair - select KeyPair and enter your username and service account Private Key. Be sure to include begin and end statements in the key. 
     
     IMPORTANT: If this is your first time connecting to a service account using a keypair and you do not have an existing ODBC driver, you must download the before using this connection method. If you are using Power BI Service, you do not need to download the driver. 
8. Use the Navigator to find your database, schema, and table/view.
9. Do one of the following:
   • Use the data as is - select Load.
   • Preview, modify, or filter the data - select Transform Data.
     

There are three main options for data prep for Power BI. Knowing where to prepare your data guarantees better report performance, scalability, and maintainability. 

• Snowflake (Source): Best for heavy lifting — complex joins, enterprise cleansing, pre-aggregations, and global filtering before data reaches Power BI.
• Power Query (Transformation): Best for report-specific tweaks — light dimension joins, field renaming, and filtering out unneeded rows to keep the dataset lean.
• DAX (Modeling): Best for dynamic interactivity — user slicers, custom KPIs, dynamic aggregations, and time-intelligence calculations

Import vs Direct Query

When you first connect to a data source such as Snowflake, SQL Server, or an enterprise database, Power BI asks, "How should we connect to and load this data?"

The table below compares the key features of each.

• Choose Import for fast report performance, full modeling/DAX capabilities, and standard dataset sizes.
• Choose DirectQuery when dealing with massive datasets, when real-time data is mandatory, or when strict database-level security policies apply.

Security Feature Comparison

In addition to differences in key features, the table below highlights the primary distinctions between the two connection modes concerning granular data access and governance.

Key Takeaways:

• Import (Power BI RLS): Best for static, straightforward security setups where dataset performance is the main priority. Logic must be maintained inside Power BI.
• DirectQuery (Snowflake RAPs): Best for strict enterprise governance. Security rules are managed centrally in Snowflake and enforced in real time using those users' SSO identity across all tools.