Topics Map > Tableau
Publication request review workflow explained
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 apir@provost.wisc.edu.
Here is the workflow in a glance:
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
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:
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
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
| Done | Task | Environment |
|---|---|---|
|
☐ |
Review Cookbook Information
|
Cookbook |
|
☐ |
Change Functional Area, if needed
|
Cookbook |
|
☐ |
Review History and Comments for:
|
Cookbook |
|
☐ |
Dashboards
|
Tableau |
|
☐ |
Determine Access Restriction for the Workbook
|
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
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
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.