Empowering Self Service Analytics with Embedded Tableau

Photo by Adeolu Eletu on Unsplash

Intro

One of the most powerful and often over-looked aspects of Tableau Server is the ability to enable users to perform self-service analytics. This has been an area of focus in the last few Tableau releases with the ability to create a new workbook from scratch and the most recent addition of AskData. Then layer a custom portal on top of these already robust capabilities and you’re able to empower all users to ask and answer their own questions in a very efficient manner, as well as reduce costs by not needing to give full Creator licences to all users.

Why Self-Service

Enabling self-service is about getting the right data to the right people and allowing them to ask and answer their own questions. It removes the feedback loop of business users making requests and IT developers creating reports which slows down the speed to insights. Ultimately the people who are most familiar with what the data represents are in the best position to analyze it. However, this comes with challenges. The first is the skill required to consume raw data, often requiring the ability to write SQL queries and a deep knowledge of database tables and relationships. It also can be a nightmare to manage, often with data being extracted from the database getting altered, shared, and altered again. It’s easy to lose track of which report is based on which data. One off reports may also be built and shared by email and eventually lost to an inbox cleanup down the road. Creating an environment where curated data can be easily shared, analyzed with intuitive tools and then saved in a centralized location, is crucial for successful self-service. The method I’m going to discuss today uses Tableau Server combined with a custom built portal to deliver the solution.

Embedding

Many of the features discussed in the post can be used natively in Tableau without any additional work. However, layering a portal on top allows us to expand our use cases, add custom functionality, and layer in additional UI. We’ll discuss how to script some of the more repetitive tasks required to set up self-service analytics and customize the look and feel of the content to make it even easier to access. There is still value in a lot of these concepts such as creating and publishing curated datasets, managing content with projects, and utilizing the AskData and web-edit features. I encourage everyone to get started with these areas even if designing a custom portal isn’t an option at this time.

Requirements

The way we are going to structure our self-service environment is as follows:

• There will be published datasets, in this case Tableau Extracts, which are not the underlying data sources of dashboards but may be related (will discuss this more later)
• Each user will have their own sandbox project where they can save their work
• Users will not be able to see the content of anyone else’s sandbox but will see content in public projects
• Users can not save work to these public projects

Setting up Users and Permissions

For context, this example uses a portal that has its own version of local authentication and is set up with Trusted Authentication with Tableau Server. Users exist on both the server and the portal but are created through the portal.

In order to achieve the outline highlighted above we need to follow a few steps each time we add a user to our portal, all of which will be automated using the Tableau REST API. I won’t provide a deep dive into the actual code written to enable this as Tableau has an extensive resources page for the API including examples (REST API Documentation), but I will cover from a high level the different calls being used.

The primary steps we will be scripting

1. Add the User

First, we need to create the user on Tableau Server in order to keep authentication on the portal in-sync with Tableau server, we can trigger this from the portal and provide a form that sends the information to Tableau.

Reference: Add User to Site

2. Create their Sandbox

Each time a user is created we will use a scripted process to create their sandbox project and assign a structured name, in this case ‘sandbox-{username}’.

Reference: Create Project

3. Assign Permissions

This is the most complex step and has multiple parts:

• Set the permissions for the default “All Users” group to Deny Save for all public projects (this only needs to be done once in the beginning - all new users are automatically added to this group when created and inherit these permissions). If you don’t want the users to see the public projects as grayed out options when they save you can also Deny View permissions. This is possible because denying a user the ability to view a project does not prevent them from viewing the dashboards in that project.
• Set the permissions for the default “All Users” group to Deny All for the new user’s sandbox project. With this set up all new users are added to the “All Users” group by default and will inherit the permission we set now, preventing us from having to set permissions on every sandbox project for every new user. For example if we already have Jim and Michael on the site each with their own sandbox project, when we add Dwight we don’t need to deny him permissions to Sandbox-Jim and Sandbox-Michael. He inherits those denies from being in the “All Users” group.
• Set the permissions for the New User to Allow All for their sandbox. This takes advantage of Tableaus permission structure. Permissions given to an individual user will override permissions at the group level.

Note: If you have tiered users and don’t want to blanket deny “All Users” you can create a new group to handle this and add a REST API call that adds each new user to that group when they are created. It will result in the same behavior.

In the image below you see the ‘denies’ set for All Users and the ‘allows’ set for our new user (Dwight). What’s actually implemented is shown below with Dwight having the ability to save into his own project.

Final Permissions

Reference: Add Project Permissions

Modifying permissions with the REST API can get confusing so I included an example of setting the new user’s sandbox permissions below. It is shown using JSON and the Request library for javaScript implementation, but Tableau’s examples will show how to do this with Python or Java.

Creating Datasets

Now that an environment is created for our users to work in we need to provide them with some curated datasets. These don’t necessarily need to be the same data sources used for the published dashboards but may be similar. In my experience when developing a Tableau dashboard one ends up with many fields that were only used for visualization purposes and won’t make sense to normal business users. By publishing a separate data source specifically for self service we can remove all of those fields and any additional information that may have been important for the dashboard but not for everyday analysis. After removing unnecessary fields we can go through and make sure every field has a meaningful name (First_Order_date_v3_LOD_New isn’t very helpful to business users) and a helpful description added into the ‘Comment’ section.

Add a description to each field

Once this is all complete we publish our datasource into one of the public projects we created and add a tag we plan to use later as a filter, ‘Self-Service” in this case.

Tagging the data source as Self Service

Accessing the Data

With the dataset published we now need to create a page on our portal that surfaces all available datasets. Then we will provide links allowing the users to quickly jump into AskData for analysis or Web-Edit for creating a new workbook. Once again we’re going to utilize the REST API to search for all datasources available on a site and add a url parameter to filter to the tag we added earlier. This ends up being:

{TableauServer}/sites/{siteID}/datasources?filter=tags:eq:self-service

Reference: Query Data Sources

With the self-service data sources returned we then format them to present to the users and add buttons that link to the two tools mentioned above.

The buttons will take the user to a page with an iframe holding the embedded view of the respective tool. For AskData this would look like:

<iframe src=’http://{Tableau Server}/askData/{DataSourceName}></iframe>

And for Web-edit:

<iframe src=’http://{Tableau Server}/authoringNewWorkbook/{Random String}/{DataSourceName}#{Random Number}></iframe>

Note: Substituting in any string/number will work however to enable multiple users analyzing the same data source concurrently it’s recommended to use a random generator to create those, since they act as id’s.

If we are using the pre-cleaned datasource for a published dashboard and want the user to be able to easily jump to the cleaned up underlying data we can add links to our dashboard pages as well.

The business users can now take full advantage of all of the features native to AskData and Web-Edit right in the portal. They will be able to see the descriptions we added when they hover over a field as well as additional metadata (metadata not shown in Web-Edit, only the descriptions).

And they can create visualizations by typing their questions.

Then when they have finished and click save, because of the way we configured the permissions, the only option they will see is their sandbox.

Conclusion

In this post we’ve created an environment of self-service analytics. We’ve provided curated data sources to our business users that allow them to ask their own questions in a controlled way. They now have the ability to create their own dashboards and reports that they can access without us worrying about a cluttered Server where other users need to dig through hundreds of uncertified reports. We utilized the REST API to script the heavy lifting and wrapped everything in a portal to create an easy to use UI. Once everything is set up the process of adding a new user, configuring permissions, creating a new project, having a user access a dataset, building a view and saving it for later, can all be captured in one GIF (see below), not bad for 45 seconds. This is large step in driving a culture of analytics for an organization.