> For the complete documentation index, see [llms.txt](https://documentation.immuta.com/2024.3/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.immuta.com/2024.3/integrations/azure-synapse-analytics/reference-guides/azure-synapse-analytics.md).
# Azure Synapse Analytics Integration
This page describes the Azure Synapse Analytics integration, through which Immuta applies policies directly in Azure Synapse Analytics. For a tutorial on configuring Azure Synapse Analytics see the [Azure Synapse Integration page](/2024.3/integrations/azure-synapse-analytics/configure-azure-synapse-analytics-integration.md).
## Overview
The Azure Synapse Analytics is a policy push integration that allows Immuta to apply policies directly in Azure Synapse Analytics Dedicated SQL pools without the need for users to go through a proxy. Instead, users can work within their existing Synapse Studio and have per-user policies dynamically applied at query time.
## Architecture
This integration works on a per-Dedicated-SQL-pool basis: all of Immuta's policy definitions and user entitlements data need to be in the same pool as the target data sources because Dedicated SQL pools do not support cross-database joins. Immuta creates schemas inside the configured Dedicated SQL pool that contain policy-enforced views that users query.
When the integration is configured, the Application Admin specifies the
* **Immuta Database**: This is the pre-existing database Immuta uses. Immuta will create views from the tables contained in this database, and all schemas and views created by Immuta will exist in this database, such as the schemas `immuta_system`, `immuta_functions`, and the `immuta_procedures` that contain the tables, views, UDFs, and stored procedures that support the integration.
* **Immuta Schema**: The schema that Immuta manages. All views generated by Immuta for tables registered as data sources will be created in this schema.
* **User Profile Delimiters**: Since Azure Synapse Analytics dedicated SQL pools do not support array or hash objects, certain user access information is stored as delimited strings; the Application Admin can modify those delimiters to ensure they do not conflict with possible characters in strings.
For a tutorial on configuring the integration see the [Azure Synapse Integration page](/2024.3/integrations/azure-synapse-analytics/configure-azure-synapse-analytics-integration.md).
### Data Source Naming Convention
Synapse data sources are represented as views and are under one schema instead of a database, so their view names are a combination of their schema and table name, separated by an underscore.
For example, with a configuration that uses `IMMUTA` as the schema in the database `dedicated_pool`, the view name for the data source `dedicated_pool.tpc.case` would be `dedicated_pool.IMMUTA.tpc_case`.
You can see the view information on the data source details page under **Connection Information**.
## Policy Enforcement
This integration uses webhooks to keep views up-to-date with the corresponding Immuta data sources. When a data source or policy is created, updated, or disabled, a webhook is called that creates, modifies, or deletes the dynamic view in the Immuta schema. *Note that only standard views are available because Azure Synapse Analytics Dedicated SQL pools do not support secure views.*
## Data Flow
1. An Immuta Application Administrator [configures the Synapse integration](/2024.3/integrations/azure-synapse-analytics/configure-azure-synapse-analytics-integration.md), registering their initial Synapse Dedicated SQL pool with Immuta.
2. Immuta creates Immuta schemas inside the configured Synapse Dedicated SQL pool.
3. A Data Owner [registers Synapse tables](/2024.3/data-and-integrations/registering-metadata/register-data-sources/query-backed-tutorial.md) in Immuta as data sources. A Data Owner, Data Governor, or Administrator [creates or changes a policy](/2024.3/secure-your-data/authoring-policies-in-secure/policies-explained.md) or [user](/2024.3/people/immuta-users/how-to-guides/managing-attribute-and-group.md) in Immuta.
4. Data source metadata, tags, user metadata, and policy definitions are stored in Immuta's Metadata Database.
5. The Immuta Web Service calls a stored procedure that modifies the user entitlements or policies and updates data source view definitions as necessary.
6. A Synapse user who is subscribed to the data source in Immuta [queries the corresponding data source view](/2024.3/secure-your-data/data-consumers/query-data/synapse.md) in Synapse and sees policy-enforced data.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://documentation.immuta.com/2024.3/integrations/azure-synapse-analytics/reference-guides/azure-synapse-analytics.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.