User Data Functions (UDFs) provide a secure, reusable logic layer for calling Microsoft Fabric REST APIs through a Fabric client. By centralizing authentication, authorization, and orchestration logic in a function, you can expose Fabric operations without embedding credentials or API logic throughout your applications. After a function authenticates with a service principal, it can perform only the operations allowed by that identity permissions and scopes. Combined with Azure Key Vault and Fabric generic connections, this approach helps keep secrets out of your code while maintaining explicit, governed access to Fabric resources.
Overview
This post explores a recommended pattern for calling Fabric REST APIs from a User Data Function, why service principal authentication matters, and how to securely manage credentials using Key Vault.
While this post demonstrates triggering a pipeline, the same pattern can be used to:
- Create and manage Fabric items
- Manage workspaces
- Run jobs
- Perform capacity operations
- Call other supported Fabric REST APIs
Before exploring implementation, we’ll review three key principles that make this pattern secure, reusable, and governable.
Functions become a secure Fabric API gateway
Instead of hardcoding orchestration logic across apps, notebooks, pipelines, or reports, you can centralize it in a function:
- The function decides what operation to run.
- The service principal provides controlled access to Fabric.
- The Fabric client calls the underlying REST API.
The same pattern can call any supported Fabric operation
The function becomes a reusable entry point for Fabric automation across Power BI, apps, notebooks, APIs, and other Fabric experiences.
- Run jobs, including pipelines.
- Read or update workspace metadata.
- Create, update, or manage Fabric items.
- Perform capacity read/write operations.
- Call other public APIs allowed by the service principal’s scopes.
Permissions stay explicit and governed
Because the function uses a service principal, access is governed by the permissions assigned to that identity. This gives you a clean separation: the function owns the business logic, the service principal controls access, and Fabric executes the operation.
Trigger a pipeline with UDF
Before you start, ensure you have:
- A Fabric workspace
- A User Data Function (UDF)
- A service principal with the required Fabric permissions
- An Azure Key Vault that stores the service principal secret
- A Fabric generic connection configured for Key Vault access
Architecture pattern
At a high level, the pattern works as follows:
- App or Fabric workload invokes the UDF.
- UDF retrieves the service principal secret from Azure Key Vault.
- UDF creates a Fabric client using the service principal (SPN) credentials.
- Fabric client calls the Job Scheduler API to trigger the pipeline.
- Results are returned to the caller.
Sample code
At a high level, the implementation uses three functions: a helper function to build a FabricClient using service principal credentials, a helper function to trigger a Fabric Data Pipeline through the SDK, and a main UDF that brings everything together by retrieving the service principal secret from Key Vault, creating the Fabric client, and invoking the pipeline.
Checkout full sample for this scenario.
def invoke_pipeline_with_spn(
keyVaultClient: fn.FabricItem,
workspaceid: str,
pipelineid: str,
tenantid: str,
clientid: str,
keyVaultUrl: str,
spnSecretName: str,
) -> str:
try:
logging.info("Fetching secret from KV")
# Step 1: Get the Key Vault credential from Fabric connection
credential = keyVaultClient.get_access_token()
client = SecretClient(vault_url=keyVaultUrl, credential=credential)
spn_secret = client.get_secret(spnSecretName).value
logging.info("Fetched secret from KV")
# Step 2: Create FabricClient with SPN credentials
fabric_client = _create_fabric_client(
tenantid=tenantid,
clientid=clientid,
client_secret=spn_secret,
)
logging.info("Created Fabric client")
# Step 3: Trigger the pipeline using FabricClient SDK
result = _run_fabric_pipeline(
fabric_client=fabric_client, workspaceid=workspaceid, pipelineid=pipelineid
)
logging.info("Ran Fabric pipeline")
return json.dumps(result, indent=2)
except Exception as e:
logging.error(f"invoke_pipeline_with_spn failed: {str(e)}")
return json.dumps({"status": "error", "message": str(e)})
Troubleshooting tip: If you run into issues, check if SPN has access to the workspace and if the Key Vault permissions are set correctly.
Real-world example: Automate project workspace setup in Fabric
For example, an internal project onboarding app can use a User Data Function to automate setup for a new project in Fabric. When a business user requests a project, the app invokes the function with the project name, owner, environment, capacity requirements, and project preferences. The function then uses Fabric REST APIs to spin up the project easily.
- The app invokes the User Data Function with project metadata, workspace configuration, and capacity target.
- The function retrieves the service principal secret from Key Vault and creates a permissioned Fabric client.
- The Fabric client creates the workspace and configures capacity.
- Once the workspace is provisioned and configured, project teams can immediately begin creating Fabric assets such as lakehouses, warehouses, notebooks, and pipelines.
Next steps
User Data Functions provide a secure and reusable way to expose Fabric automation behind governed APIs. By combining service principals, Azure Key Vault, and the Fabric SDK, you can centralize operational logic while keeping credentials protected.
Ready to get started? Explore the User Data Functions documentation and adapt this pattern to your own Fabric automation scenarios.