The Various Built-in Roles in Azure Synapse Analytics Workspace

Understanding Azure Synapse Analytics

Azure Synapse Analytics is a powerful platform that offers a range of built-in roles to manage access to Synapse resources. These roles provide administrators with the ability to control the actions that users and applications can perform within a Synapse workspace. The assignment of roles can be managed by Synapse Administrators, who can assign roles at different scopes within the workspace. When creating a new workspace, the creator is automatically given the Synapse Administrator role at the workspace level.

Let’s explore some of the key built-in roles available in Azure Synapse Analytics:

  1. Synapse Administrator: This is the highest level of role in Synapse Analytics, providing full control over the entire workspace. A Synapse Administrator can manage all resources within the workspace, including databases, SQL pools, data flows, and security settings. The responsibilities include managing workspace, security/ access control, SQL pool management, and integration with other Azure services.

It is important to assign the Synapse Administrator role only to trusted individuals or teams who require complete control over the workspace.

  1. Synapse Contributor: This role allows users to create, update, and delete resources within the Synapse workspace. However, they do not have control over access to the workspace. The Synapse Contributor role provides substantial control over resources, including data flow and integration, limited security control, and resource provisioning/deprovisioning.
  2. Synapse SQL Administrator: This role focuses on managing and configuring SQL pools, databases, and data flows within the workspace. SQL pool management, database management, SQL query and script execution, limited control over workspace resources, and security/ access control are some of the responsibilities of a Synapse SQL Administrator.
  3. Synapse Apache Spark Administrator: This role allows users to run and review notebooks, submit Spark jobs, and perform actions on Spark artifacts and activities. However, they do not have permissions to grant access to other users. The Synapse Apache Spark Administrator role provides full access to Apache Spark pools and read access to all published code artifacts.
  4. Synapse Artifact Publisher: This role enables users to read, update, delete, and create published code and outputs, including scheduled pipelines. However, they do not have permission to run the code or grant access to other users. The Synapse Artifact Publisher role allows for viewing notebooks, Spark jobs, and pipeline outputs.
  5. Synapse Artifact User: This role has limited permissions at the workspace level. Users with this role can read published code artifacts and create new ones, but they cannot publish or run the code.
  6. Synapse Compute Operator: This role allows users to monitor and cancel Spark jobs submitted by any user. They can also submit Spark jobs, view all jobs, and access Spark pool logs.
  7. Synapse Monitoring Operator: This role is specialized for monitoring workloads within Synapse. Users with this role can read published code artifacts and completed notebooks, including output logs of pipeline runs. However, they cannot run or cancel pipelines, Spark notebooks, or their jobs.
  8. Synapse Credential User: This role is necessary for using secrets in credentials and connected services during runtime and configuration. It allows for the execution of pipelines protected by system identity credentials, access to data via linked service, and executing pipelines requiring credentials.
  9. Synapse Linked Data Manager: This role is used to create and manage credentials, linked services, and managed private endpoints. It enables the establishment of credential-protected managed private endpoints that utilize linked services.
  10. Synapse User: This role allows users to list and examine Integration runtimes, SQL pools, Apache Spark pools, published linked services, and login credentials. However, additional publicly available code artifacts are excluded. Users can create new artifacts but require additional permissions to run or publish them.


These roles can be assigned at different scopes, such as subscription, resource group, workspace, or even individual resources. Role assignments can be done using various methods, including Azure Portal, Azure PowerShell, Azure CLI, or Azure Resource Manager templates. It is essential to follow the principle of least privilege when assigning roles, granting only the necessary permissions for users to carry out their specific tasks and responsibilities. Over-assigning privileges can pose potential security risks.

Find out more about how Skrots, our company, can assist you at Explore the range of services we offer at Thank you for reading!

Show More

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button