Tableau Row Level Security overview

If you are here for the first time (or come back frequently), there’s a new Row Level Security page (up in the top toolbar) which gives an overview of your options in Tableau and links to the individual blog posts that dive into detail. Recommended reading for everyone, and it will be kept up to date over time with any changes or additions to functionality.



PowerPoint Template Find and Replace in Behold! Emailer 2.1 Beta 1

A long time request I’ve heard from customers is the need to update the images of Tableau Server vizes within a PowerPoint presentation. Behold! Emailer 2.1 now includes a tab for doing this type of “find and replace” on an existing PowerPoint (PPTX) presentation file. You specify the slide and the location of the viz you’d like to pull, and the tool will download that image, insert it into the PPTX file, and replace whatever other image was previously on that slide. It should be a real time saver for those who have to do this type of activity regularly.

The instructions for using it are all in the README , including the caveat that this is only for slides that have a single image in them currently. Please let me know if you have any issues or other requests around this use case.


Multiple Table (Normalized) Hyper Extracts

The currently available Beta 1 of Tableau 2018.3 includes a long-requested feature for creating multiple table Hyper extracts — that is to say, each table you see in the connection pane will be brought in and stored as separate tables in a single Hyper extract file. Why is this so exciting? Because it’s the end of the need for Defusing Row Level Security in Tableau Data Extracts (Before They Blow Up) Part 1 (and Part 2)!

Starting in 2018.3

  • The design for row level security will be the same in both live connections and extracts
  • Extract files with security will create much faster
  • Best practices for entitlements tables are now feasible in Extracts

Let’s dig into the essentials and how we can make this work for effective Row Level Security.


Behold! Emailer 2.0 Beta 1 Available

After a long pause in development, the first Beta of Behold! Emailer 2.0 is now available for testing on GitHub, in a new repository. For a full overview, please see the new README . Here is the quick description:

  • Complete redesign of the interface, separating configurations from the actions, with an Activity Log to show the progress of your actions and any running schedules
  • Queuing system for all actions. You can trigger off individual file exports, start a batch export run all while it continues to run the scheduled e-mails from Tableau Server.
  • Vastly improved README file
  • Single and Batch e-mail modes allow for specifying the type of file export: fullpdf, pdf, png or csv
  • Tested up to Tableau Server 2018.1
  • Full code review internally to clean up and use modern C# best practices
  • Upgraded Npgsql package in the binary release for better stability

It’s just a Beta 1 because I need feedback on any errors or issues, but it is already much improved and more stable than any of the old 1.2 versions.

Session-level Single-Sign On

Tableau Server doesn’t currently (as of 2018.2) have a dedicated “service” for authentication when doing Single Sign-On. Instead, a Tableau Server session is established the first time you load a Viz using a given SSO method. Whether using Trusted Authentication, Windows Authentication, or SAML, when the first viz loads, that is when the authentication actually happens, and after that point, there is a Tableau Server session cookie, so that the authentication doesn’t have to happen continuously.

Traditionally, particularly for Trusted Authentication, instructions have been given to request and send a new ticket for each load of any Viz. But this introduces extra, unnecessary authentication requests, and can even lead to a “race condition” when you are loading multiple Vizes in the same page, where sessions are being created and overriding each other as separate tickets are processing at the same time. This same issue can affect ANY of the SSO methods when loading multiple vizes.

The Hidden / Empty Viz Solution

As mentioned above, once the first Viz has been authenticated, there is a Tableau Server Sesssion cookie that will be used for all subsequent requests. So to create a “login” service, we simply need to login as quickly as possible to a Viz. This is very similar to what you need to do for Trusted Authentication SSO into the full Tableau Server UI.

The simplest Viz possible is all we need (literally, a single filter on a page using a totally blank Data Source can be used). Every user is the Tableau Server should have access to this Viz. As soon as the user is authenticated into the main application, you should load the simple viz — if using Trusted Authentication, this request should include the trusted ticket. You can hide the Viz div under something or out of sight (the div shouldn’t actually have visibility:hidden though because some browsers don’t like that prior to the Viz being initialized), so that the user doesn’t see this load process. Or do it quickly in a page that then redirects to the next page. It’s up to you.

Session Timeout with Trusted Tickets

The one advantage of continually sending Trusted Tickets is that the Tableau Server session is continually extending as each ticket is sent. If you only do one Trusted Ticket to establish a session, how do you keep from timing out and sending the user to the Tableau Server sign-in box? The answer is to set your own timer cookie, and whenever it times out, reestablish the session using the Empty Viz. You shouldn’t need to do this with SAML or AD, because they will automatically call out and reestablish their sessions, but you could.


Tableau Server sessions will end naturally based on the value you have set for them using tabadmin / TSM. Actually forcing a Tableau Session to sign-out is a little tricky — recent versions of Tableau Server understand a SAML IdP Signout, or you could try to use the REST API to signout, but in the latest version of Tableau Server, the REST API technique requires reverting to a simpler, less secure type of session cookie.

Revisiting The Tenets of Multi-Tenancy

Since there’s been so much time and better examples and code, I went back and did a major revision of the The Tenets of Tableau Templates on Multi-tenants which I highly advise everyone reading. It’s the most thorough explanation out there of how to correctly handle SaaS / Multi-Tenancy or Dev->Test->Prod promotion. And no, you do not need Interworks PowerTools to do this process, although they do have some nice features.

Replicating Workbooks with Published Data Sources

If you were ever wondering why there is both a REST API and a Document API produced by Tableau, or why we at this blog put out tableau_tools implementing both of those functionalities (and more!), this use case will illustrate it clearly.

The desired action: Specify a workbook on one Tableau Server site to be downloaded and published to a different Tableau Server site (we’ll call this “replicating over”).

Why it is complicated: Best practice with Tableau Workbooks is to Publish their Data Sources separately, to aid in managing the metadata and to provide for unbreakable Row Level Security, among other great reasons. This means we need to download any Published Data Sources that the Workbook is connected to, and publish them over to the new site as well. Simple enough, right?

After a lot of research and testing, the following steps are required to accomplish this correctly:

  1. Download all of the workbooks you are interested in using the REST API
    1. Makes sure to do this one Project at a time, because Workbooks can have the same name if they are in different Projects
  2. Open up each of the workbook files to look at which published data sources (use tableau_tools.tableau_documents)
    1. Scan through all of the datasource elements in the Workbook XML.
    2. Check to see if each datasource is a published data sources
    3. If a published data source is found, find the contentUrl referenced within
  3. Query all Data Sources using the REST API. Search for any Data Source whose  contentURL attribute matches one of those from the workbooks
  4. Download the matching data sources using the REST API
  5. Publish the data sources across to the new Site
    1. You will need to provide the credentials for any data source at publish time, since there is no way to securely retrieve them from the originating site
  6. Once published, retrieve the details from the new Data Source on the new site, including the new contentUrl property
  7. Reopen the workbook file, then change the Site and Data Source cotentUrls to match the the newly published Data Sources on the destination site
  8. Publish the workbook using the REST API

Luckily, all of this is possible using tableau_tools, and there is a sample script available now showing how to do it.