Fabric Semantic Model - Add member to Role through API

A semantic model in Microsoft Fabric acts as a business-friendly layer over raw data, enabling meaningful insights and seamless integration with tools like Power BI. Below is a step-by-step guide to creating a semantic model using the Fabric API.

Using the Fabric REST API

Step 1: Prerequisites

• Ensure you have Contributor permissions in the workspace.
• Obtain the required API scopes: SemanticModel.ReadWrite.All or Item.ReadWrite.All.
• Verify that your Microsoft Fabric license supports semantic modeling.

Step 2: Construct the API Request

Use the following endpoint to create a semantic model:

POST https://api.fabric.microsoft.com/v1/workspaces/{workspaceId}/semanticModels

Replace {workspaceId} with your workspace's unique ID.

Step 3: Define the Request Body

Provide details for the semantic model, including its definition and metadata:

{
"displayName": "SemanticModel 1",
"description": "A semantic model description.",
"definition": {
"parts": [
{
"path": "model.bim",
"payload": "ew0KICAiY29tcGF0a..GVzIjogWyBdDQogIH0NCn0=",
"payloadType": "InlineBase64"
}
]
}
}

• displayName: Name of the semantic model.
• definition: Base64-encoded payload defining the model structure.

Step 4: Execute the Request

Send the request using tools like cURL, Postman, or any HTTP client:

curl -X POST \
-H "Authorization: Bearer <ACCESS_TOKEN>" \
-H "Content-Type: application/json" \
-d @request_body.json \
"https://api.fabric.microsoft.com/v1/workspaces/{workspaceId}/semanticModels"

Step 5: Validate Response

• A 201 Created response confirms successful creation.
• A 202 Accepted response indicates that provisioning is in progress. Use the Location header to track status.

Best Practices

• Use meaningful names and descriptions for easier identification.
• Ensure all required tables or data sources are properly linked before creating the model.
• Regularly update and maintain semantic models to reflect changes in data structures.

By following these steps, you can efficiently create and manage semantic models in Microsoft Fabric, enabling robust analytics and reporting capabilities.

Thanks for reaching out. Here are some recommended solutions:

1.      Use the Power BI REST API to Post Dataset Users

Since fabric semantic models inherit much of their structure and management from Power BI REST API is still the standard way to manage member assignments to semantic model roles.

The relevant API calls are:

·         POST Datasets- POST Dataset User (or Post Dataset User In Group): This API adds a specified user, group, or service principal to the semantic model’s permissions. This is the API to use for assigning users/groups to the semantic model roles you’ve created.

o   Interface: POST https://api.powerbi.com/v1.0/myorg/datasets/{datasetid}/users (for use the group/workspace version).

o   Required Payload: You will need to specify the principal type  (User, Group, App), the identifier and the DatasetUserAccessRight which includes the semantic model role name.

o   C# implementation: you would use an HttpClient in your C# application to make this authenticated POST request to the Power BI REST API endpoint after your Semantic Model has been created in fabric.

2.      Use XMLA Endpoint (for Advanced TMSL/C# AMO)

If you require a pure TMSL or a more direct, lower-level control, the XMLA Endpoint is the traditional path for managing Analysis Services objects, including semantic model roles and membership.

·         Method: You would connect to the Fabric workspace’s XMLS endpoint using a C# application leveraging the Analysis Services management objects (AMO) library.

·         Action: You can execute a TMSL CreateOrReplace command that includes the full members definition for the role. This method gives you the flexibility to manage the entire semantic model metadata, including role membership, programmatically.

3.      Leverage Dynamics RLS

If the goal is to enforce Row-level Security (RLS), a common and scalable pattern is to avoid assigning individual users to roles entirely and instead implement Dynamic RLS.

·         Mechanism:

o   Create a single RLS role (e.g., “All Users”) in your semantic model and assign all users (or a large security group) to it.

o   In the role’s DAX filter expression, use the USERPRINCIPALNAME() function.

o   Create a lookup table (or security table) in your semantic model that maps User Principal Names (UPNs) to their allowed data (e.g., UPN to Region ID)

·         Automation: You can automate the updating of this lookup table via a Fabric Notebook or another ETL process. This is much easier to manage than constantly updating role assignments via API calls.

Summary of Automation Methods:

o   Direct Assignment: best for explicitly assigning individual groups to RLS roles.

Tool/API: PowerBI REST API (Post Dataset User)

C# Path: HttpClient POST Request

o   Advanced Metadata: best for full control via raw TMSL/AXML

Tool/API: XMLA Endpoint

C# Path: C# AMO Library

o   Scalable RLS: Best for Large , frequently changing user base

Tool/API: Dynamic RLS +Fabric notebooks/ETL

C# Path: C# updates to data source (optional)

Let me know if you need any further help with this. We'll be happy to assist.

If you find this helpful, please mark this as answered.