What is a Service Principal in Power BI?

If you're managing or developing with Power BI, you've likely heard the term "service principal" and wondered what it is and why you should care. In short, it’s a powerful but often misunderstood feature that unlocks serious automation and application integration. This guide will explain exactly what a service principal is in plain English, why it's a game-changer for your workflow, and how to set one up step-by-step.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

What Exactly is a Service Principal?

Think of a service principal as a special "robot" user account for your applications. While your personal work account (like sarah@yourcompany.com) is tied to you, a specific human being, a service principal is an identity created exclusively for a piece of software, a script, or an automated service.

Technically, it's an application identity within Microsoft Entra ID (formerly known as Azure Active Directory) that can be granted specific permissions to access resources, like your Power BI workspaces. Instead of using a person's password, which changes, requires multi-factor authentication (MFA), and goes away when an employee leaves, a service principal authenticates using its own credentials — an unchangeable Application (client) ID and a secret key or certificate.

Think of it this way: you give a person (a user account) a key card with their photo on it to access an office building. If they leave the company, you deactivate their card. You give a delivery drone (an application) a generic, special-purpose key card (a service principal) that only opens the mailroom door. It’s more secure and a lot easier to manage for automated tasks because you're not relying on a specific person's login credentials.

Why Use a Service Principal with Power BI?

Using a service principal isn't just a technical nicety, it solves some very common and practical problems. Here are the main reasons why it’s become a best practice for working with Power BI at scale.

Benefit 1: Securely Automate Your Workflows

Let's say you have a recurring task, like refreshing a dataset or exporting a report to PDF every morning using a PowerShell script. How does that script log into Power BI?

• The Bad Way: You hard-code your own email and password directly into the script. This is a huge security risk. Anyone who sees the code has your password. Plus, when you're forced to change your password every 90 days, the script breaks until you update it.
• The Better Way: You create a service principal for your script. The script then uses the service principal's Application ID and a client secret to log in. This process, called "headless authentication," requires no human interaction, doesn't store your personal credentials, and isn't affected by your password changes.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

Benefit 2: Embed Power BI Content in Your Applications

This is probably the most common reason to use service principals. Imagine you've built a custom web application for your customers and you want to display Power BI reports and dashboards directly within it. You don't want to make every single one of your customers buy a Power BI Pro license and create their own account just to see the data.

This is known as the app-owns-data embedding model. Here’s how a service principal makes it work:

1. Your web application uses the service principal's identity to connect to the Power BI service.
2. It requests an embed token for a specific report.
3. It uses that token to render the interactive report inside your application's user interface.

Your end-users never need to know Power BI is involved. They log into your app, and the service principal handles all the back-end communication securely. It’s the official, Microsoft-recommended way to provide a seamless embedded analytics experience.

Benefit 3: Granular and Auditable API Access

The Power BI REST API lets you programmatically manage nearly every aspect of the service — from creating workspaces and managing datasets to deploying content. When running these administrative tasks, using a service principal is far safer than using a highly-privileged user account.

You can define what the service principal is allowed to do. For example, you can grant it permissions to only read report data, or only refresh datasets. If its secret key were ever compromised, the potential damage is limited to only those activities. This "principle of least privilege" is a core concept in cybersecurity.

Benefit 4: Bypassing Multi-Factor Authentication (MFA) Hurdles

Organizations rightly enforce MFA to protect user accounts. However, this is a showstopper for automated scripts that run non-interactively. A script can't exactly tap "Approve" on a push notification. Because service principals are designed for these unattended machine-to-machine scenarios, they authenticate directly without requiring MFA, allowing your automations to run smoothly and securely.

How to Set Up a Service Principal for Power BI

Setting up a service principal involves a few steps in both the Azure portal and the Power BI Admin portal. You’ll generally need admin permissions in both environments to complete this process.

Let’s walk through it.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

Step 1: Register an Application in Microsoft Entra ID

First, you need to create the identity for your application in Microsoft Entra ID (which you might still know as Azure AD). This "app registration" is what creates the service principal.

1. Log into the Azure Portal.
2. Navigate to Microsoft Entra ID (you can search for it in the top bar).
3. In the left menu, select App registrations, then click + New registration.
4. Give your app a descriptive name, like "Power BI Embedding App" or "Daily Refresh Script".
5. For "Supported account types," the default option (Single tenant) is usually what you want.
6. You can leave the "Redirect URI" section blank for now.
7. Click Register.

Once it's created, you'll be taken to the app's overview page. Immediately copy and save the Application (client) ID and the Directory (tenant) ID. You'll need these later.

Step 2: Create a Client Secret

Next, you need to generate a "password" for your service principal, which is called a client secret.

1. From your app registration's page, click on Certificates & secrets in the left menu.
2. Click + New client secret.
3. Add a short description (e.g., "Script credential") and choose an expiration period. Be mindful of this — your automation will break when it expires!
4. Click Add.

This is critical: A secret will be generated. Copy the Value of this secret immediately and store it somewhere safe like Azure Key Vault or another secrets manager. Once you navigate away from this blade, the value will be masked, and you'll never be able to see it again.

Step 3: Enable the Service Principal in the Power BI Admin Portal

Just because you've created a service principal doesn’t mean it can access Power BI. You need to explicitly give it permission.

1. Go to app.powerbi.com and navigate to Settings > Admin portal.
2. In the Admin portal, select Tenant settings and scroll down to the Developer settings section.
3. Find the setting titled "Allow service principals to use Power BI APIs" and enable it.
4. For best practice security, don't apply this to your entire organization. Instead, create a dedicated security group in Microsoft Entra ID (e.g., "PBI Service Principals") and add your new app's service principal to it. Then, select the "Specific security groups" option here and add that new group. This ensures only approved applications can access Power BI.

Step 4: Grant Permissions in a Power BI Workspace

Finally, your service principal needs access to the specific Power BI content (workspaces, reports, datasets) it needs to interact with. You grant access just like you would for a human user.

1. Go to the Power BI workspace you want the service principal to access.
2. Click the Access button at the top.
3. In the side panel, enter the name of the application you registered in Step 1. It should show up in the search results.
4. Select it, and assign it a Role:
5. Click Add.

That's it! Your service principal is now fully configured and ready to be used in your code.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

Putting It Into Practice: A Simple Example

So how do you actually use the Application ID, Client Secret, and Tenant ID you saved? Here is a simple Python script example using the msal library to authenticate as the service principal and list datasets in the workspace you configured.

import msal
import requests
import json

# Your Service Principal Credentials
TENANT_ID = 'YOUR_DIRECTORY_TENANT_ID'
CLIENT_ID = 'YOUR_APPLICATION_CLIENT_ID'
CLIENT_SECRET = 'YOUR_CLIENT_SECRET_VALUE' # Keep this secure!
WORKSPACE_ID = 'YOUR_POWER_BI_WORKSPACE_ID'

# Power BI API Details
AUTHORITY = f'https://login.microsoftonline.com/{TENANT_ID}'
SCOPE = ['https://analysis.windows.net/powerbi/api/.default']
API_URL = f'https://api.powerbi.com/v1.0/myorg/groups/{WORKSPACE_ID}/datasets'

# 1. Create a confidential client application instance
app = msal.ConfidentialClientApplication(
    client_id=CLIENT_ID,
    authority=AUTHORITY,
    client_credential=CLIENT_SECRET
)

# 2. Acquire a token from Entra ID
result = app.acquire_token_for_client(scopes=SCOPE)

# 3. Use the token to call the Power BI API
if "access_token" in result:
    access_token = result['access_token']
    headers = {
        'Authorization': f'Bearer {access_token}',
        'Content-Type': 'application/json'
    }

    # Make the API request
    response = requests.get(API_URL, headers=headers)

    if response.status_code == 200:
        datasets = response.json()
        print("Successfully retrieved datasets:")
        print(json.dumps(datasets, indent=2))
    else:
        print(f"Error calling API: {response.status_code}")
        print(response.text)
else:
    print("Error acquiring token.")
    print(result.get("error"))
    print(result.get("error_description"))

This script shows the core flow: use the credentials to get an access token, then present that token to the Power BI API to prove who you are and what you're allowed to do. You can use this pattern to perform any action available in the Power BI REST API.

Final Thoughts

Service principals might seem technical at first, but they are simply secure, non-human identities crucial for automating, embedding, and managing Power BI effectively. By using them, you replace risky, user-based scripts with a more robust, secure, and governable solution designed for modern data workflows.

Setting up service principals, managing API access, and creating automated reports across all your different marketing and sales tools can quickly become complex. We built Graphed to remove that headache. Instead of scripting API calls across platforms like Google Analytics, Shopify, and Salesforce, we let you connect them with a single click and use simple, natural language to build real-time dashboards instantly. This automates the technical overhead so you can get straight to the insights.