Carnegie Mellon University
Office of the CIO  ›  Computing Services  ›  Services  ›  Administrative and Business  ›  Data, Reporting and Analytics  ›  Enterprise Power BI  ›  Get Started with Power BI

Get Started with Power BI

Learn how to use the Power BI collection of tools to connect data, transform it, and create compelling visualizations like charts, maps, and graphs, available across desktop, web, and mobile.

Those using Mac or Windows computers can view reports, add comments, download data, create subscriptions, and receive alerts through our Power BI Service. You can also use the service to make new reports and build data models directly.

LOG IN TO POWER BI SERVICE

Are you a viewer of a Power BI report?

This short YouTube video from Guy in a Cube will guide you in navigating Power BI reports effectively.

Essentials

Become familiar with fundamental terminology and concepts, and learn how to navigate the Power BI environment.

  1. Review the Basics of the Power BI Service to master core terms and concepts.
  2. Learn how to get around in the Power BI Service to locate workspaces, apps, and dashboards.
  3. Practice: Log in to Power BI Service and explore the interface.

Data Connections and Ingestion

Learn how to connect Power BI to various data sources safely and efficiently.

  1. Understand the difference between Import vs Direct Query.
  2. Connect to our Snowflake enterprise data lake. 
  3. Practice: Connect to a Snowflake schema and perform basic data cleanup in Power Query before loading.
  4. (Optional) Connect to an Excel dataset. Note: Snowflake is the preferred data source. 

Report Creation

Transform raw data into compelling visuals and leverage.

  1. Review the Create Report Visuals tutorial to learn how to develop charts, maps, and graphs.
  2. (Pro Licenses) Prepare your data for AI to improve Copilot results. 
  3. Ensure your report meets the guidelines outlined in the Accessibility documentation.
  4. Practice: Build a single-page report that includes at least three distinct visual types (e.g., a bar chart, a trendline graph and a KPI card).

Sharing, Lifecycle, & Governance

Share reports securely with internal or external stakeholders while adhering to university data governance policies.

  1. Understand your workspace roles by reviewing the Workspace Setup guidelines. 
  2. Review sharing protocols: use Publish an app for internal teams, and understand the strict parameters of using Publish to the web for external audiences.
  3. (Optional) Learn how to manage your content lifecycle leveraging deployment pipelines.
  4. Practice: Request a collaborative workspace if you don’t already have one. Practice publishing your completed report to a test app.

Next Steps

Quick Reference

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 app.

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 Snowflake ODBC driver 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.

The table below presents recommended use cases for each of the three main approaches to data preparation and transformation.

Task Type

Snowflake Data Source

Power Query
(M Language)

Data Analysis Expressions (DAX)

Data Integration / Joins

Combine data for unified, performant views (Best for large, complex merges)

Light merges or lookups (e.g., small dimension tables)

Not recommended

Data Cleansing / Standardization

Fix inconsistencies, handle duplicates and nulls, and apply standard naming conventions

Minor cleanup like trimming text or removing nulls (report-specific)

Not recommended

Aggregations / Summaries

Pre-aggregate data for performance (e.g., daily to monthly summaries)

Not recommended

Dynamic aggregations only (e.g., SUM, AVERAGE, etc.)

Filtering

Create filtered views reused across reports

Apply report-specific filters; reduce dataset size for model efficiency

Use slicers or filters interactively

Data Formatting / Naming

Apply consistent naming and data types in warehouse views

Rename or reformat fields for readability in the model/report

Not recommended

KPIs / Calculations

Not recommended

Not recommended

Calculate dynamic metrics, KPIs, and explicit measures (e.g., Selectivity, Yield)

Time Intelligence

Not recommended

Not recommended

Use built-in functions (e.g., TOTALMTD, DATEADD, etc.)

Once you load the data, you will be asked to select your Connection settings. Each connection type has its own benefits and drawbacks, so it's crucial to select your connection mode wisely.

For most use cases, Import mode is typically the best option. DirectQuery is advisable for very large data sources or cases where Snowflake row access policies require data security.

The table below compares the key features of each.

Feature

Import

DirectQuery

Data Location

Data is copied and stored in Power BI's high-performance in-memory engine.

Data remains in the source system (e.g., Snowflake).

Data Freshness

Data is only as fresh as the last scheduled refresh.

Data is real-time/near-real-time, as the source is queried with every report interaction.

Performance

Queries are processed instantly in Power BI's optimized memory.

Performance depends entirely on the speed of the source database and network.

Data Size Suitability

Best for small to medium datasets.

Best for very large datasets that cannot be imported, or when live data is essential.

DAX & Modeling

Full Functionality. Supports all DAX, including advanced Time Intelligence and calculated tables/columns.

Limited Functionality. Some complex DAX and many Power Query transformations are restricted.

Source System Load

Low. The source is only queried during scheduled data refreshes.

High. The source is queried live on every visual change, slicer click, or report open.

"Offline" Access

Yes. Once refreshed, the data is available for building/viewing reports without a source connection.

No. Requires a continuous, active connection to the source database.

In addition to the differences in key features, the table below outlines the primary differences between the two connection modes in terms of granular data access and governance.

Security Feature

Import:
Power BI Row-Level Security

DirectQuery:
Snowflake Row Access Policies

Security Location

Power BI Semantic Model (Dataset)

Snowflake

User Identity

Often uses a service account for data refresh; RLS filter is applied by Power BI Service post-refresh

Requires Single Sign-On (SSO) to pass the end-user's identity to the source

Access Control

Done via DAX security roles defined in Power BI Desktop

Done via native database policies (e.g., Snowflake RAPs or secure views)

Security Audit

Must audit access in Power BI (who can view the dataset) and the data source (who can access the service account)

Audit is centralized in the Snowflake logs, recording the end-user's live queries and the data returned

Data Governance

Requires duplication of security logic; must manage rules in two places

Centralized governance; security rules apply to all consumption tools

Preferred for...

Scenarios where data volume is low, performance is paramount, and security rules are simple/static

Scenarios with high security requirements and complex, frequently changing row-level security
Our FAQ page provides answers to many Power BI questions.