Tableau

Quick Links

• Tableau Online GitLab instance
• Tableau eLearning Portal
• Tableau Customer Portal
• Tableau Status Page
• Internal Slack channel
• External Slack channel
• GitLab Tableau Developer Guide
• GitLab Tableau Administration Guide
• Reporting Data Catalog
• Handbook Embedding Demonstration

Tableau

Tableau is our new Enterprise Business Intelligence tool. It is a leader in the Business Intelligence space. We are applying the Tableau Blueprint to launch our Tableau production environment. The Tableau Blueprint outlines the processes and best practices from thousands of Tableau customers. We will apply these processes and best practices in accordance GitLab’s TeamOps and culture.

Terms and Definitions

• Connections: The method Tableau used to communicate with a source of data.
  • Direct to Source: When Tableau uses a built in connector to communicate with source of data like Snowflake or Google Drive.
  • Virtual Connection: A curated connection where the communication to the source of data has been set by the admin team. Will generally simulate a Direct to Source connection.
  • Published Data Source: A curated connection to a single tableau that is the result of data modeling. It is stored on Tableau Online.
  • Connect to A File: A method of getting data from the files in your system into Tableau. This includes Excel files, CSV, PDF, etc.
  • Connect to A Server: A method of connecting to an online data source. This includes any connection to any online data sources, including Tableau Online and Snowflake
• Connection Credentials: The information used to certify connection to a source of data.
  • Embedded: Credentials are saved as part of the connection.
  • Prompt User: Credentials must be input every time the connection is used.
• Connection Freshness: Determines how often a connection will communicate with the source of data.
  • Live: Will send a query to the source of data each time the data is needed.
  • Extract: Well send a query when prompted to the source of data storing the result in custom micro database.
  • Scheduled Extract: An extract hosted on Tableau Online that will, on a fixed frequency, communicate with the source of data and update the stored data.
• Data Modeling: The method of combining multiple tables of data into a single result table.
  • Data Warehouse: The query to combine the table is stored in the data warehouse repository and is materialized in the data warehouse.
  • Tableau Data Modeling: Relationships are defined between tables, in the connection interface, directly in Tableau.
  • Tableau Blending: Relationships between data sources defined in the visualization construction interface.
  • Custom SQL: Using SQL within a connection to define the relationships between tables.
• Tableau Objects: The elements that a developer will work with to create visualizations.
  • Project: The folder structure maintained in Tableau Online. This is where content permissions are administered.
  • Workbook: The base file time for creating visitations.
    • View: The element that represent a chart or other visualization.
    • Dashboard: A collection of views and layout elements.
    • Story: A collection of views and layout elements where the views can be set to a specific filter or parameter value and displayed in a sequential structure.
  • Data Source: A collection of connections and data modeling that results in a single result table that can be published and a stand alone file.
  • Flow: A collection of connections and transformation steps that will typically result in creating one or more Data Sources.

Roadmap

FY24 Tableau Deployment Roadmap

We follow the nomenclature found in the GitLab Docs and will stand-up the Tableau Production program using Experimental, Beta, and Generally Available dashboards. A more complete version of the Tableau implementation roadmap can be found at this Data Team epic.

• FY24-Q1 - Experimental Dashboards
  • Ready Tableau Online environment for Production Releases
  • Move the CFO and Headcount Dashboards to full Production
  • Develop a list of Top SSOT Dashboards for GTM and Finance
  • Develop project plan for deprecating the legacy schema in Snowflake
• FY24-Q2 - Experimental and Beta Dashboards
  • GTM and Finance teams to begin migrating key content to Tableau Production
  • Design Spike: Test Tableau embedding capabilities for 1 Engineering KPI Public Handbook embedding use case
• FY24-Q3 - Generally Available Dashboards
  • Develop additional data models for R&D to support Tableau migration in Q3
  • Bring R&D, People, and the rest of the Enterprise into focus
  • Establish, communicate, and initiate the process for cutting over KPI charts in the handbook
• FY24-Q4 - Generally Available Dashboards
  • All Business departments to migrate key content
  • Complete the cutover of all KPI charts in the handbook
  • Complete Tableau migration efforts

Governance Model

Governance is the combination of controls, roles, and repeatable processes that creates trust and confidence in data and analytics. Both IT and business stakeholders on the project team are responsible for defining data and content governance together. In a successful self-service environment, the appropriate levels of governance create accountability and enable, rather than restrict, access to trusted content for users at GitLab. Governance is a spectrum, different kinds of data and content require different kinds of governance. It’s not a one-time effort because skills and expectations will evolve. Periodically evaluating governance processes will allow us to evolve and delegate more responsibilities as new analytical skills and use cases develop.

We use a self-governing model at GitLab. In a self-governing model, there is strong collaboration between IT and business users. Certified content and data sources are available, and ad-hoc content is being created regularly by Creators and Explorers. Viewers understand the delineation between certified, ad-hoc, and sandbox content states. The process of validation, promotion, and certification is well-defined and well-understood by users of all skill levels. With increasing analytical skills across the organization, the boundaries between the roles of the Modern Analytics Workflow are fluid as users switch from consuming to creating to promoting content with the appropriate level of permissions.

BIOps

Our Tableau self-governing model is administered and enforced in the GitLab Tableau Project using BIOps. The BIOps approach will leverage GitLab’s repository, maintainer and code review functionality to administer the governance model. Tableau does not currently have a Git integration so our BIOps is not fully automated and there are some limitations. The README file is coming soon which will describe the BIOps workflow. We will iterate on this approach with the GTM and Finance teams during Q1 and Q2 and adjust and adapt as needed.

Tableau Project Architecture

The Project Architecture in Tableau Online is replicated and governed in the GitLab Tableau Project. Please see the GitLab Tableau Project for more details. Below are descriptions of the project folders and a sample of the project architecture found in Tableau online.

The top-level folders in our Tableau Project, and their corresponding levels of governance, include:

• Development: content in this folder intentionally includes no governance, in order to enable users to quickly prototype. As such it should be considered to be sandbox content.
• Ad Hoc: content in this folder has been reviewed and approved by a sub-project leader, with traceability via an MR. (see project-permission-structure for a list of sub-project leaders.)
• Production: content in this folder has been reviewed and approved by sub-project leader(s) as well as project leader(s). This is the highest level of certification for Tableau content.
• Resources: content in this folder includes workbook templates and certified data sources that can be used in workbook development

BIOps Roles and Responsibilities

Please see the project-permission-structure section for details on the permissions for the BIOps roles.

1. Top Level Project Leader / Maintainer Responsibilities: The Top Level Project leaders come from the BI Platform Team. These leaders are responsible for publishing content in the Sub-Projects that role up to the Top Level Projects and are responsible for maintaining the GitLab Tableau Project. This role does not specifically include Tableau Online Site Administration responsibilities although several Top Level Project Leaders are also Tableau Online Site Admins.
2. Sub-Project Leader / Code Owner Responsibilities: The Sub-Project Leaders come from functional departments and teams. These leaders are responsible for reviewing and approving content for publishing in their department’s folder and in cross-functional Sub-Project folders like the Go To Market folder as Code Owners. The CODEOWNERS file in the Tableau project is the source of truth for sub-project leads who are able to review and approve MRs to publish dashboards to Production.

BIOPs Workflows

The BIOps Workflow consists of 4 stages; Access Request, Development, Ad-Hoc Publishing, and Production Publishing. Please see the README in the GitLab Tableau Project for detailed steps on the workflow to include the process for submitting a Merge Request for Tableau Production publishing, submitting an Issue for Tableau Ad-Hoc publishing, and receiving the necessary maintainer and code owner approvals from Project and Sub-Project leaders for publishing content.

graph LR
  A[Access Request]-->B
  B[Development]-->C
  B[Development]-->D
  C[Ad-Hoc Publishing]-->D
  D[Production Publishing]

1. Access Request: The Access Request stage requires completion of an Access Request. Please see the Access section of the Tableau handbook page for more details.
2. Development: All Tableau Content Development starts in the Development Project Folder. The Development Folder is a Sandbox environment where Tableau developers are free to experiment and iterate with content and share with team members for initial peer reviews. Tableau Developers can organize their Sandbox work using Collections for easy access and sharing. The Development Folder will have the same user experience as our old Sisense BI tool where team members can create and share content on demand without any approvals being required from the BI Platform team. Tableau Creators should follow SAFE development workflow guidelines when working with MNPI data in the development folder.
3. Ad-Hoc Publishing: When content in the Development Project Folder is ready for publishing, it can be published in the Ad-Hoc Project Folder if it adheres to the Ad-Hoc Data Development methodology. Please see the README for detailed steps on publishing content to the Ad-Hoc Project Folder.
4. Production Publishing: When content in the Development or Ad-Hoc Project Folders is ready for Production publishing, it can be published in the Production Project Folder if it adheres to the Trusted Data Development methodology. Content that adheres to the Trusted Data Development process will get a Certified Stamp in Production. If the content does not adhere to the Trusted Data Development requirements, but is still considered SSOT, Production grade content, the content can still be published in Production, but it will not receive a Certified Stamp. In such cases, there should be an issue with a project plan for the Tableau content to receive a Certified Stamp. Please see the README for detailed steps on publishing content to the Production Project Folder.

BIOps Workflow Examples

The flowchart below illustrates 3 examples of the BIOps publication workflow.

In Example 1, a developer is publishing a dashboard to their own Development space. No governance or approval is required.

In Example 2, a developer is publishing a dashboard to a sub-folder within the Ad Hoc space. This requires review and approval by the project leads (i.e. Functional Team leaders) of the sub-folder the dashboard will be published to. For example, if the developer is publishing a dashboard to the Sales sub-folder within the Ad Hoc space, a Sales sub-project leader will need to review and approve it.

In Example 3, a developer is publishing a dashboard to a sub-folder within the Production space. This requires review and approval by the project leaders (i.e. Functional Team leaders) of the sub-folder the dashboard will be published to, as well as review and approval by the top-level project leaders (i.e. project leaders from the Enterprise Data Team). For example, if the developer is publishing a dashboard to the Sales sub-folder within the Production space, a Sales sub-project leader will need to review and approve it, and an Enterprise Data Team project leader will need to additionally review and approve it.

flowchart TD
    A["Developer creates dashboard"]

    subgraph C["No Approval Required"]
        p1["Developer publishes\ndashboard"]
    end

    subgraph D["Requires Functional Approval"]
        mr1["Developer creates Tableau\nproject issue"] -->
        mr2["BI Team creates\nMR for approval"] -->
        mr3["Sub-project leader MR approval\nkicks off dashboard publication"]
    end

    subgraph E["Requires Functional & BI Team Approval"]
        mr4["Developer creates Tableau\nproject issue"] -->
        mr5["Data team creates\nMR for approval"] -->
        mr6["Sub-project leader\napproves MR"] -->
        mr7["Project leader's MR approval\nkicks off publication"]
    end

A --> |to publish to Development|C
A --> |to publish to Ad Hoc|D
A --> |to publish to Production|E

BI Development Excellence

Tableau Workbooks must satisfy all of the below requirements in order to be published to Tableau Production. These requirements are included in the Merge Request Template for Production Publishing (Link coming soon…).

1. The workbook uses a template in the Resources folder. If a template is not used, then at a minimum, the workbook should include the GitLab logo, handbook url, and the project path.
2. The content adheres to the Development workflow.
3. The content is the Single Source of Truth (SSOT) for a business area. The SSOT should be documented in the handbook either in a Business Domain Handbook Page, Data Guide in the Data Catalog, or both.
4. Business owner has signed off on both the functionality of the content and the validity of the numbers.
5. Technical owner has signed off on validity of the numbers.
6. The workbook uses a Certified Virtual Connection or a Certified Published Data Source.
7. Performance tuning has been performed and the workbook refreshes within 5 minutes max.

Tableau Trusted Data Certification

Tableau Workbooks that meet all requirements for Trusted Data Development and meet all requirements for BI Development Excellence (Link coming soon…) will receive a Trusted Data Certification. The certification is applied by placing a TD in the workbook title.

Tableau Data Sources that meet all requirements for Trusted Data Development will receive a Trusted Data Certification. The certification is applied using native Tableau functionality and a certified stamp is applied to the data source.

Tableau Publishing Service Level Objectives (SLOs)

Production Publishing SLO

The BI Platform team will publish production content once a week on Thursday. The due date for submitting content for publishing is Friday of the prior week which allows 4 days for the BI Platform team to review the content and publish it on Thursday of the following week.

Ad-Hoc Publishing SLO

The department sub-project leaders will publish ad-hoc content within 24 to 48 hours after it is submitted for publishing.

Development Publishing SLO

Individual Tableau developers can publish development content on-demand to their department’s development sub-project.

Deployment

Tableau Cloud leverages GitLab’s existing technology investments and integrates into our IT infrastructure to provide a self-service, modern analytics platform for our users.

Tableau Online Admins

Permissions

Pursuant to GitLab’s Transparency value, all GitLab team members will have access to all content in Tableau by default. However, as a Public Company, we have to abide by the SAFE Framework and limit access to certain sensitive and confidential data in Tableau to team members that need SAFE data to do their jobs. In Tableau, we set these SAFE data permissions via User Groups at the Project level.

User Groups

User Groups are the only prescribed method we use for setting permissions across the Tableau site. A User Group is a collection of users that can be based on a topic, project, or organization structure, that will need to have the same set of access and permissions for content. All users will be a member of the General Access user group and can be added to more User Groups as required. The assignment of users to groups will be documented and controlled from YAML files maintained in the Tableau Project in the Data Group.

Limited Access User Groups

Limited access user groups will allow business teams to manage accessibility to their published content based on rules that they’ve identified. Request for the creation of a limited access user group can be made through the All Requests template in Issues section of the Tableau project and requires the approval of that department’s sub-project lead.

List of User Groups

Each section below below corresponds to a limited access user group and the designated owner. Please note: To gain access to an user group, the designated owner will need to give approval in the AR.

General SAFE Access

• This group allows viewing of and development with data that contains material non-pulic information that should be kept SAFE. Team members must be on the Designated Insiders list to be added to this group.
• To gain access to SAFE data and be part of the SAFE Access group please submit an AR like this example, which requires manager and VP approval.

ASM AMER Commercial Restricted Access

• This project allows access to the ASM AMER Commercial sub project. It is restricted because the data contains sensitive information about sales rep activity, bookings, and segmentation.
• Please work with Keith Gliksman @keith.gliksman for access approval.

ASM EMEA Commercial Restricted Access

• This project allows access to the ASM EMEA Commercial sub project. It is restricted because the data contains sensitive information about sales rep activity, bookings, and segmentation.
• Please work with Keith Gliksman @keith.gliksman for access approval.

ASM Restricted Access

• Please work with the GTM Planning & Ops team and/or Alex Cohen @alex.cohen for access approval.

Internal Audit Restricted Access

• Please work with the Internal Audit team and/or Harinakshi Poojary @hpoojary for access approval.

People Restricted Access

• Please work with the People Analytics team and/or Adrian Perez @aperez349 for access approval.

RSA SAFE Access

• This group is for the Revenue Strategy and Analytics team and is restricted because analysis performed are confidential planning efforts that may impact people roles. Team members must be on the Designated Insiders list to be added to this group.
• Please work with the Sales Strategy team and/or Olga Falkenhof @ofalken for access approval.

Sales Development SAFE Access

• Team members must be on the Designated Insiders list to be added to this group.
• Please work with Keith Gliksman @keith.gliksman for access approval.

Self-Service SAFE Access

• Team members must be on the Designated Insiders list to be added to this group.
• Please work with the Self-Service team and/or Max Fleisher @mfleisher for access approval.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

groups:
  - group_name: group 1
  - group_name: group 2
  - group_name: group 3

users:
  - user_name: team_memebr@gitlab.com
    site_role: Site Administrator Creator
    auth_setting: SAML
    groups:
      - group 1
      - group 2

  - user_name: other_team_member@gitlab.com
    site_role: Viewer
    auth_setting: SAML
    groups:
      - group 1

Project Permission Structure

User Groups are applied at the Project and Sub-Project levels. We have two types of User Groups that we apply, Administrator User Groups and Access Control User Groups. The Admistrator User Group gives permissions relating to what administrative tasks the user can do on the project such as moving content, deleting content, and changing permissions on the project. The Access Control User Group gives permissions relating to what access the user has such as viewing and publishing content.

The Admistrator User Group and the Access Control User Group can be customized to meet the unique needs and requirements of each Project and Sub-Project on the Tableau site. This allows for flexibility to add or customize security controls on an as-needed basis. The assignment of a User Groups permission rule set for a Project or Sub-Project will be documented and controlled from YAML files maintained in the Tableau Project in the Data Group.

No content is published in the top level Production, Ad-Hoc, and Development Projects. Content is only published in the Sub-Projects under the Top level projects which is a best practice for content, access, and security control. Top level Project (Production, Ad-Hoc, and Development) Leaders will always be a member of the Central Data Team’s BI Platform team and will need a site role of Creator to function as Project Administrators for publishing content. Data Champions will serve as Project Leaders for the Sub-Projects for their respective functional areas. The Sub-Project Leaders will be added to the applicable Administrator and Access Control Groups in order to have the right permissions to lead the Sub-Project.

The standard permission rules for top level Projects are noted below:

Below is an example of User Groups and Permissions applied to a Data Team Sub-Project where only Data Team Members can publish in the project, but All Team Members can view the content in the Sub-Project. At the Sub-Project Level, for the User Group Name, Limited Access Team Members can replace the All Team Members User Group Name for limited access.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

projects:
  - project_name: Example Project
    content_permissions: ManagedByOwner
    project_path: Project Name/Project Name/
    permission_set:
      - group_name: group 1
        permission_rule: view
      - group_name: group 2
        permission_rule: project_lead

Capabilities

Capabilities are a Tableau concept that we apply. Permissions are made up of capabilities, or the ability to perform a given action on a piece of content, such as view, filter, download, or delete. Permission rules are the setting for each capability (allowed, denied, or unspecified) for the user group. Permission rules have templates available that make it easier to assign capabilities quickly.

Templates group sets of capabilities that are often assigned together based on common user scenarios such as View, Publish, and Administer. When we assign a template, its included capabilities are set to Allowed, with the rest left as Unspecified. The templates are built to have all of the capabilities a user would need, for example the Publish template includes everything from the View template plus additional capabilities.

Below are examples of Permission Templates we use at GitLab. Permission templates are applied to Tableau content.

Below are examples of Site Roles that we use. Individual users are assigned to site roles and given permissions via site role. Site roles act as an upper limit of what a Tableau User can do on the site.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

permission_templates:
  - name: view
    projects:
      Read: Allow # View
    workbooks:
      Read: Allow # View
      Filter: Allow # Filter
      ViewComments: Allow # View Comments
      AddComment: Allow # Add Comments
      ExportImage: Allow # Download Image/PDF
      ViewUnderlyingData: Allow # Download Summary Data
      ShareView: Allow # Share Customized
    data_sources:
      Read:  Allow # View
      Connect: Allow # Connect
      ExportXml:  Allow # Download Data Source
    data_roles:
      Read: Allow # View
    flows:
      Read: Allow
      ExportXml:  Allow # Download Flow
    lenses:
      Read: Allow # View
    metrics:
      Read: Allow # View
    virtual_connections:
      Read:  Allow # View
      Connect: Allow # Connect
    databases:
      Read:  Allow # View
    tables:
      Read:  Allow # View

  - name: project_lead
    projects:
      ProjectLeader: Allow # Set Project Leader

Access

Tableau Online Access

Users can request access by creating an issue in the access requests project documenting the level of access required and assigning it to a designated Tableau Online admin after acquiring manager approval. To make a request, please navigate to the Choose a template dropdown menu and select the Tableau_Request template to get your AR started.

All users will be given access to their Division’s sub-project by default. For access to another team’s space please submit your request in a Tableau Project issue via the All Requests template and tag the designated Lead Approver(s) for that team from the BIOps Roles and Responsibilities section for approval in your issue.

Tableau Desktop users will also need a Yubikey set up in Okta to access content published in Tableau Online. Due to our new security method that only accepts Biometric or Yubikey for authentication, please request a Yubikey via the Yubibot to ensure that logging into Tableau will be secure and smooth. Currently biometrics are not supported yet in Tableau Desktop.

Once approved, the BI Platform team will then add the user to the okta-tableau-users Google Group, add the user in Tableau Online and assign the correct license, then add the user to the right Tableau Group.

Tableau Desktop Access

Creators with an active license to Tableau Online is encouraged to use Tableau Desktop for development. Locally developed Data Sources or Workbooks can later be published to Tableau Online. All Creators will be assigned access to Tableau Online and Desktop. The BI Platform team will assign Dekstop keys from the Licenses section of the Tableau Customer Portal. Those assigned a Desktop key can follow email instructions from Tableau to set up their client.

One can download Tableau Desktop using the links below, or follow the link from the Home Page of Tableau Online.

• Tableau Desktop Releases Download
• Tableau Prep Builder Releases Download

Tableau Desktop vs. Tableau Cloud

Tableau offers two ways to create / edit workbooks and data sources, either via the Desktop client or Cloud (web) version. However, we recommend to develop in Desktop, as this version will have full functionality for editing and development.

Benefit of each version:

Desktop Tableau Desktop provides FULL functionality. All the capabilities available by Tableau will be accessible in Desktop and you can create data sources, workbooks, dashboards, groups, sets, formatting, customized calculations, etc.

Cloud Tableau Cloud allows users to interact with content (that you’ve created and published with Desktop). Cloud will also allow you to create workbooks / dashboards, but not data sources, sets, in-depth formatting, etc.

Fore more details on features offered by each version please see this Tableau article on Web Authoring and Tableau Desktop Feature Comparison

Data Source Access: Tableau Online

Please refer to this Connecting to Data in Tableau Guide for more details.

Data Source Access: Tableau Desktop or Tableau Prep Builder

Important: In order to connect Tableau Desktop to Tableau Cloud, you need to set up a [Yubikey]({{ ref “okta/#i-want-to-add-touch-id–face-id–face-authentication–yubikey-to-okta” }}) in Okta. Fingerprints will not work. Please see the Tableau Online Access section above for more details on how to order a Yubikey.

Education

GitLab team members who realize the full potential of analytical insights can do powerful things with data. But having a platform like Tableau and access to data isn’t enough; we need to assure that our users are prepared to use Tableau effectively.

Support

In addition to the proactive steps we’ve taken with self-service help resources and education initiatives, we want to provide our user community with the support they need in case these two approaches do not answer their question or resolve the issue.

Monitoring

As more and more users are onboarded and the use of analytics grows across GitLab, Tableau becomes mission-critical for data-driven decisions. Without monitoring, a “set-it-and-forget-it” deployment can be met with inadequate resources that fail to support the workload of highly-engaged users. Ongoing, proactive monitoring is required to operate and support our deployment at scale and meet the expectations of our user community.

Because Tableau is integrated with our enterprise architecture, including hardware, network, databases, and applications, understanding how everything interoperates is key for routine monitoring, performance, and troubleshooting. The monitoring function is focused on these systems and their integration with Tableau Cloud. It is primarily technical in nature and performed by IT roles. Tableau Cloud Site Administrators will work together to ensure the platform meets evolving business needs.

Tableau Online Status

To check the current status of Tableau Online and if there are any reported outages, visit the Tableau Status Page. On that page you can also sign up for notifications in the event of an outage. For reference, GitLab’s Tableau Online instance is located in United States - West - (10AZ).

View page source - Edit this page - please contribute.