Skip to content

You are viewing documentation for Immuta version 2.8.

For the latest version, view our documentation for Immuta SaaS or the latest self-hosted version.


Audience: Data Owners and Users

Content Summary: Tableau Desktop is a tool for exploring data, performing analysis, and creating visualizations. Tableau Desktop can connect to the Immuta Query Engine and consume data via Immuta's SQL Access Pattern. This page outlines how to connect Tableau Desktop to Immuta and publish workbooks with real-time policy enforcement.


Tableau is an official technology partner of Immuta, and its market-leading visualization software makes it easy to leverage your policy-enforced data from Immuta.

Connect to Immuta with Built-In / LDAP Query Engine Authentication

You can connect Tableau Desktop to Immuta by creating a PostgreSQL data source. Users will use their SQL Credentials to authenticate with the Query Engine, unless an alternative Query Engine Authentication is configured.

Connecting to Immuta with Tableau

For more details related to connecting to analytic tools, see the Analytic Tools section.

Connect using Tableau Desktop

  1. Select the PostgreSQL option in the To a Server section in the Connect dialog.

  2. Enter the hostname and port for the Immuta Query Engine.

  3. Enter immuta for the database name.

  4. Select Username and Password as the authentication type.

  5. Enter your SQL Credentials for username and password.

  6. If the Query Engine is configured to use SSL (the default for most installations), check Require SSL.

Publishing Workbooks with Built-In / LDAP Query Engine Authentication

Use Prompt User

Be sure to select the Prompt User authentication mode when publishing Tableau data sources and workbooks. This ensures that users will be prompted for their Immuta SQL credentials or LDAP credentials when viewing workbooks. This allows Immuta to apply fine-grained policies and audit each user.

General Tips

Below are five guidelines for keeping Tableau workbooks performant, with special considerations for how Immuta can change the dynamic between the data and visualization layers.

  1. Push down operations to the native database. Perform calculations at the lowest level possible, since this requires the fewest “translations” between services. This may mean making exposing a new view of your data source within Immuta, then connecting to it within Immuta.
  2. Keep data types consistent. If the source data are text, make sure that the Immuta data type is text. This is especially important for dates, which can be inefficient for Tableau to detect and convert. It is most performant for the data to be stored in DATE format at the database level.
  3. Follow Tableau filtering best practices. Adding too many filters, or inefficient filters, can cripple the performance of your dashboards, with or without Immuta.

    1. Perform filtering using Dashboard Actions rather than visualization-level filters.
    2. Only filter on low-cardinality columns. Stated another way, only filter on dimensions that will remove large portions of the population.
    3. Leave any user-specific filtering to Immuta, rather than using Tableau Server User Filtering policies. By making individuals log in to dashboards with their Immuta credentials, you'll push down filtering to our layer.
  4. Use Custom SQL and Level of Detail expressions sparingly. Custom SQL and Level of Detail expressions are useful features for generating exactly the dataset required for an analysis. However, they can also create inefficient queries because they require the placement of one or more subqueries in the FROM clause. When possible, it’s best to expose complex operations within Immuta as views, and then build charts off of these views.

  5. Leverage multiple data sources, rather than a single comprehensive one. If you want to leverage information from multiple data sources, it is best to optimize each visualization with only its requisite data. For example, suppose you want to create two charts, A and B. Chart A requires a JOIN between two tables, so you create this as Data Source 1 in Tableau. If Chart B does not require the JOIN operation, then it will be more performant to create a Data Source 2 that reuses the data. On the other hand, you may consider using Join Culling if your data sources come from the same database and have indexing set up.