Topics Map > Tableau

Publication request review workflow explained

This explains the workflow steps in more details

Purpose

This document explains in more details our review process that has been outlined in the UW-Madison Enterprise Tableau Development and Publication Process.

The review steps are separately explained. Also, a couple of checklists have been created and published on our KB (Knowledge Base) site to help different parties with their review.

Any questions about our review process should be directed to dapir@provost.wisc.edu.

Here is the workflow in a glance:

Review Workflow

 

In Development

in development

Who is responsible for this step:

Developer

What do they check:

Before building the workbook, the developer ensures that a similar workbook does not exist already. A list of workbooks and their information can be retrieved through RADAR (Repository for Administrative Dashboards and Reports).

reaches out to experts and stewards to make sure they have the correct domains, logic, classification, and access details.

Based on the type of request, the developer follows steps we documented in our KB pages (chose the related document) to create the workbook and start the governance process:

https://kb.wisc.edu/msndata/search.php?cat=7586

There is a checklist created to help developers ensure everything is good before they start a review. This checklist can be found on the following KB page:

Review a Tableau Workbook Checklist (for Developers)

What do they add in the comments section:

Indicate if this version is a publication or modification request.

If it is a modification request, explain the changes made.

Explain any deviations from standards and permissions.

Add a link to the Staging version of the workbook. 

 

DAPIR Approval

DAPIR approval

Who is responsible for this step:

DAPIR (Data, Academic Planning & Institutional Research)

What do they check:

The DAPIR staff will check the specification to make sure all necessary fields are filled.

The review also includes checking the workbook for format and functionality (style, accessibility, proper links, etc.). The following internal KB was created with a checklist to help DAPIR staff with their review:

Review Checklist - DAPIR

Review Exceptions:

Data Steward review will no longer be required for minor revisions of workbooks that do not change the way data is defined, collected, or presented. Examples of these changes include updating a workbook's data source to include a new year of data, transferring a workbook's owner to another developer, minor visual changes for accessibility reasons, and copy edits. If the change you are making to a workbook falls into this category, please put the phrase Minor Revision at the beginning of your change comment. After completing their review, DAPIR will approve and activate the specification without Data Steward involvement. The developer will not have to activate the specification. If DAPIR determines that Data Steward review is in fact needed, they will make note of that and advance the specification to Data Steward review as is standard.

What do they add in comments section:

If sending back to developer:

Indicate what is the reason to send the request back.

If everything looks good:

Add the following phrase in the comments section:

"Functionality OK. Sending to Steward(s) for review."

If the Staging link is missing, add it. This will help Steward(s) to review the proper version.

 

Data Steward Approval

Data Steward approval

Who is responsible for this step:

Data Stewards

What do they check:

Stewards review the report and Cookbook specification details to determine data and definitions accuracy, access restriction and data classification.

The review checklist for this stage has been outlined in detail in the old Steward Handbook document. Check that each of the following items are accurate, complete, and appropriately used in the workbook.

Review Checklist for Stewards

Review checklist for stewards
Done Task Environment

  ☐

Review Cookbook Information

  • Title, Purpose, Description, Additional Info
  • Functional area
  • Data sources
  • Update/refresh schedule

Cookbook

  ☐

Change Functional Area, if needed

  • Send an email to the appropriate Steward(s) about the change. Cookbook will not send an automatic email to inform them this occurred.

Cookbook

  ☐

Review History and Comments for:

  • Description of any changes made
  • Any request to allow download of summary (crosstab) data or full data
  • Any deviation

Cookbook

  ☐

Dashboards

  • Filter dropdown options, including ‘all values’, ‘no values’ & null values.
  • Filter combinations
  • Tooltips
  • Data fields and terminology
  • Definitions listed in the Info link
  • Download summary (crosstab) or full data for each chart/graph, if applicable

Tableau

  ☐

Determine Access Restriction for the Workbook

  • Intended audience, if specified
  • Level of detail displayed in dashboards
  • Level of detail available upon download, if requested
  • The topicality and sensitivity of the information in the workbook
  • Consider FERPA, HIPAA or other applicable laws/policies/standards

Cookbook

  ☐

Collaborate with Developer or Data Governance where needed

Cookbook

  ☐

Click Approve Specification to send to Data Gov Final QA stage

Cookbook

What do they add in comments section:

If sending back to developer:

If sending back to Developer or DAPIR, explain the reason and/or the fixes needed.

If everything looks good:

Explain any changes made to functional area or access restriction.

Due to the strategic nature of institutional reports, it is important that the reviews are done in a timely manner. Please make sure you are reviewing within 2-3 days and maximum of five days.

 

DAPIR Final QA

DAPIR final approval

Who is responsible for this step:

DAPIR

What do they check:

Double checks that all changes have been incorporated in the report and in Cookbook specification. Also, check to make sure access restriction and classification matches the Stewards approval comment if any related comment is added.

What do they add in comments section:

Document any changes made.

 

Requestor Activation

Requestor activation

Who is responsible for this step:

Developer

What do they check:

Publishes (if modification) or moves (if new publication) the report into production.

Activates Specification in Cookbook.

Checks links in RADAR the next day.

What do they add in comments section:

At this stage, the Developer cannot make changes, but they can still post a comment after Activating.



KeywordsTableau   Doc ID128463
OwnerMehrnaz A.GroupData KB
Created2023-05-22 13:07:33Updated2024-09-19 09:48:11
SitesData, Academic Planning & Institutional Research
Feedback  0   0