Tableau

Tableau

Tableau is our 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 with GitLab’s TeamOps and culture.

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 one off content is being created regularly by Creators and Explorers. Viewers understand the delineation between certified, one off, 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 Cloud 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 Cloud.

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.
• Production: The Tableau Production folder environment is a designated area where validated, high-quality content is published and accessible to end users for business-critical reporting. Content in this folder has been reviewed and approved by Project Leaders.
• Resources: content in this folder includes workbook templates and certified data sources that can be used in workbook development

Tableau Content Publication

Tableau Workbooks and Data Sources can be published to two folder environments: Development and Production. The following details the publication process for each folder environment.

Publication to Development Folders

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. Tableau Creators should follow SAFE development workflow guidelines when working with sensitive SAFE/PII/MNPI data in the Development folders.

Publication to Production Requirements

The Production Folder is a separate environment where Tableau users can find dashboards that have been peer-reviewed and tested by project leads of the respective functional areas. Content in the Production folders has met the following requirements:

1. Documentation
   • Issue Creation: Publication of content requires an issue which is automatically labeled for categorization and search-ability.
   • Documentation in Handbook: Documentation to be created in GitLab Handbook and linked to in Tableau content description and listed on dashboards
2. Validation Approvals
   • Tableau Project Lead (Business Department Owner) Approval: The Tableau Project Lead must approve the promotion.
   • Technical Owner (Data Steward) Sign-off: Project Lead may request a Technical Owner sign off on the validity of the data and content.
   • Cross-Division Development: Content that is cross-division requires a review by multiple Business Owners. Cross Division content includes GTM, etc.
3. Data Security
   • Data Security: For SAFE or Restricted data, appropriate folder and/or data source access permission controls must be applied. For general access data, confirmation that no restricted (SAFE) data is used is required.
4. Uniqueness
   • Content Uniqueness: Content is unique to Production
5. Requirements for Workbook Formatting
   • Workbook Formatting: The workbook must include the GitLab logo.
   • Content Descriptions: Workbooks and Data Sources should have a 1-2 concise description providing the purpose of the content.

Publication to Production Procedure

First-Time Promotion to Production

1. Developer Publish to Development: The Developer publishes the content to a Tableau Development folder. This is the initial step where content is prepared for review and eventual promotion.
2. Developer Creates an Issue: The Developer creates a GitLab Issue which will document the promotion process to Production. Use the template Tableau Publish Workbook or Data Source to Production which lists all necessary request documentation and requirements.
3. Developer Confirms Content Validity: Developer ensures content meets promotion criteria requirements as documented in Issue. The Developer will then assign the issue to the associated Department Project Lead for approval, signaling that the content is ready for review.
4. Review Process: The Project Lead will review the issue and content. They will check for compliance with Production requirements and assess the content’s readiness. If needed, the Approvers will propose corrections or updates to the content. The Developer will need to address these before proceeding.
5. Final Promotion: Once all requirements are met and approval is granted, the Project Lead moves the content from Development to Production. This step officially makes the content available for business use.

Editing and Updating Content in Production

There are two options for editing or updating content which is in Production:

1. Update and Overwrite Original: This is required for any major changes to a workbook or data source. Changes include replacing or editing a data source, altering or adding logic, custom sql, or calculated fields. This is the preferred option where the developer edits the workbook or data source and save it to the Development folder. It is then reviewed and inspected. After approval it the Project Leader will overwrite it to Production.
2. Allow Developer to Edit in Production: Allow me 48 hours to edit/update access to alter in Production content myself. This is only allowed for small changes such as cosmetic improvements, spelling corrections, small filter changes or urgent issues.

Tableau Trusted Data Certification

Tableau Workbooks that meet all requirements for Trusted Data Development 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 Style Guide

For more guidance on design best practices and resources, please refer to our Tableau Style Guide handbook page.

Tableau Publishing Service Level Objectives (SLOs)

Production Publishing SLO

Project Leaders are responsible for their respective department folders. They provide review and approvals for requests to promote content to Production.

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 Unused Content Archival Policy and Process

To maintain an efficient, clean, and user-friendly Tableau environment an automated archival process has been implemented. This policy outlines the procedure for archiving unused and inactive content within our Tableau GitLab Cloud environment. Tableau GitLab Public and Sandbox are excluded from this policy.

Scope of Archiving:

90+ days unused workbooks and data sources are archived and made inaccessible by search or via direct links. Archived items can be retrieved upon request to the BI team. The archival process is automated and occurs on the 15th of each month by moving content to the Admin Archive Folder.

Archival Exclusions:

1. Workbooks and dependent data sources published to Tableau GitLab Public.
2. Items for which the owner has requested retention, indicated by the Tableau tag Do NOT Archive.
3. Content stored in Personal Folders will not be archived, as it is only viewable by the owner and does not clutter the environment.

Archival Contact: For questions or requests regarding archived content, please reach out to the BI team. Click here for administrative archival documentation.

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 Standard Data Team Issue template in Issues section of the Tableau project.

List of User Groups

Each section 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-public 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.

• Customer Success Access: Please work with the Customer Success team and/or Brandon Butterfield @bbuterfield for access approval.

• Ecosystem Sales and Operations: Please work with the Ecosystem Sales and Operations team and Evan Ludaway @Evan Ludaway or Niles Jamshaid @Niles

• 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. Please work with the Sales Strategy team and/or Olga Falkenhof @ofalken for access approval.

• *Sales Development SAFE Access: Please work with Keith Gliksman @keith.gliksman for access approval.

• *Self-Service SAFE Access: - Please work with the Self-Service team and/or Max Fleisher @mfleisher for access approval.

*Note: Groups with asterisk are where team members must be on the Designated Insiders list to be added to this group.

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 Administrator 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 Administrator 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, 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 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.

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.

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

Tableau Licenses

The Data Team will regularly review users’ Tableau activity to determine if users have the appropriate license type, and will potentially downgrade users whose activity suggests they would be adequately served by a lower license tier. License adjustments will be made to optimize the pool of available licenses and will be based on the following activity guidelines:

• To maintain a Creator license the team member must meet any of the following:
  • Have published a datasource within the past 90 days
  • Have connected to Tableau Cloud from Tableau Desktop within the past 90 days
• To maintain an Explorer license the team member must meet any of the following:
  • Have accessed the web authoring environment within the past 90 days
  • Have published a workbook within the past 90 days
• To maintain a View license the team member must meet any of the following:
  • Have accessed a View within the past 90 days
  • Have accessed a Datasource within the past 90 days

Inactive licenses will be reclaimed quarterly following our Data Health and Security practices.

Tracking License Usage

• Utilization & Usage by License Type
• Assigned Licenses (Admins only)
• Licenses Used
• Actions by Users
• eLearning Usage (Admins only)

Access

Tableau Cloud Access

Users can request access by creating an issue in the access requests project using the Tableau_Request issue template. Follow the instructions in the template to ensure it will be picked up by the Central Data Team for provisioning.

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 Creators who use Tableau Desktop will need a Yubikey set up in Okta to access content published in Tableau Cloud. If you’re unsure which one to get, the recommended device is the YubiKey 5C Nano FIPS. Currently biometrics are not yet supported 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 Cloud and assign the correct license, then add the user to the right Tableau Group.

Tableau Desktop Access

Creators with an active license to Tableau Cloud are encouraged to use Tableau Desktop for development. Locally developed Data Sources or Workbooks can later be published to Tableau Cloud. All Creators will be assigned access to Tableau Cloud and Desktop. Tableau Desktop keys are automatically assigned by Tableau Cloud when first connecting.

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

• Tableau Desktop Releases Download
• Tableau Prep Builder Releases Download

If you want to automatically download the latest version of Tableau Desktop for Mac, you can use this link.

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 developing in Tableau 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

Tableau Data Sources

Tableau Data Source Connection Policy

This policy provides guidance on approved data source connections in Tableau to ensure data consistency, security, and support across all dashboards.

1. Primary Data Source: Snowflake

   • Role: Snowflake is the main data source, housing core business logic and transformed data. All data requiring transformations or business rules must originate from Snowflake.
   • Support: The Tableau Admin team fully supports Snowflake connections in Tableau.

2. Additional Approved Data Sources

   • Permitted Sources: Google Sheets, Google Drive, Excel are permitted for external data that doesn’t duplicate Snowflake data.
   • Support: The Tableau Admin team will provide support for the listed permitted connections in Tableau.
   • Policy Compliance: The connection must meet policy guidelines, avoiding duplication of Snowflake data and excluding additional business logic or transformations that belong in the warehouse pipeline.

3. Additional Data Connections and Available Connectors

   Tableau provides a wide range of Supported Connectors and Tableau Exchange Connectors. Generally, all data should be routed through the approved data pipeline. However, direct connections to alternate data sources are permitted in specific cases, such as when data does not require merging with business logic, and a direct connection provides efficiency and quicker time implementation.

   These direct connections may only be used under the following policy:

   • Approvals: The connection must be approved by the Data Team and source system business and technical owner. Start a new request here.
   • Security: The connection must be secure. A security audit may be required.
   • Policy Compliance: The connection must meet policy guidelines, avoiding duplication of Snowflake data and excluding additional business logic or transformations that belong in the warehouse pipeline.
   • Data Privacy and Governance: Data access should be restricted as necessary to protect sensitive information, such as PII and MNPI. Coordinate with the Tableau Admin Team to ensure proper data security and privacy measures are in place.

Data Source Access: Tableau Cloud

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 in Okta. Fingerprints will not work. Please see the Tableau Cloud 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.

E-learning Access Instructions

Explorer

Explorer: Below are your instructions on how to access eLearning for Explorer.

1. Go to explorer-elearning.tableau.com
2. Create (or login to) your TableauID account
3. Confirm your email address via the TableauID confirmation email
4. Go to https://explorer-elearning.tableau.com and log on using your TableauID
5. Register at the Tableau Learning Center with Access Code: This should have been DM’d to you by your Tableau provisioner, if not please Slack the provisioner directly
6. Start using eLearning by clicking on a Course or Learning Path.
7. Return to https://explorer-elearning.tableau.com to continue using Tableau eLearning.

Creator

Creator: Below are your instructions on how to access eLearning for Creator.

1. Go to https://elearning.tableau.com
2. Create (or login to) your TableauID account
3. Confirm your email address via the TableauID confirmation email
4. Go to https://elearning.tableau.com and log on using your TableauID
5. Register at the Tableau Learning Center with this Access Code: This should have been DM’d to you by your Tableau provisioner, if not please Slack the provisioner directly
6. Start using eLearning by clicking on a Course or Learning Path.
7. Return to https://elearning.tableau.com to continue using Tableau eLearning.

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 Cloud Status

To check the current status of Tableau Cloud 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 Cloud instance is located in United States - West - (10AZ).

View page source - Edit this page - please contribute.