A large nonprofit in the education space worked with Keyrus on a data initiative to combine institutional education data and provide researchers with deeper insight into student populations. Prior to this engagement, the organization was providing institutions with eight static PDFs, one for each of their KPIs.
Keyrus conducted data source gap analysis, Tableau dashboard development, Tableau server configuration, row-level security modeling, and automated deployment processes.
The project began with a discovery phase in order to gain a deeper understanding of the goals and expectations for the Tableau dashboard initiative.
Previously, the reports were created via Oracle Business Intelligence and delivered as PDFs. The goal was to migrate the existing reports into Tableau and increase overall functionality and depth.
There would be eight KPI reports and an executive summary report. These reports would help researchers identify patterns in different student populations that might explain why students are successful or unsuccessful. Through these insights, institutions and initiatives would be better equipped to make decisions and develop policies that would help students succeed.
The dashboards needed to be self-service and contain row-level security to restrict access to data based on the user groups identified by the organization.
Before starting dashboard development, Keyrus completed a whiteboarding session for each of the proposed dashboards, creating mockups for each. Keyrus then cross-referenced these models with the data currently available in the organization’s Oracle data mart. There were a number of changes to make to meet the requirements of the mockups.
After the gap analysis and in parallel with ETL changes, Keyrus developed eight Institution-level dashboards (meaning single institutions would be the main audience of these reports).
Since student academic data is private to the institution that submitted the data, the Tableau dashboards needed to incorporate row-level security so organizations could only see data that they submitted.
The nonprofit required three levels of access:
Institution level - users that can see only a single institution
System or Initiative level - users that have access to multiple institutions’ data
Superuser level - internal users who can see global view (all data)
The Keyrus solution includes a User Access table with a single record per institution, since this is the most granular level of security required.
Since there are multiple users who will have access to an institution’s data, the usernames with access will be concatenated in a single cell. The purpose for this is to avoid any case of data duplication. The table is joined to the views that hold data for the eight KPIs. On the Tableau side, a Data Source Filter was applied on the datasource with logic like this:
CONTAINS([USERNAME],USERNAME()) OR ISMEMBEROF(‘SuperUsers’)
Thus, if the record contains the username of the user viewing the workbook, the user will be able to view that record. If the user is dubbed a superuser, they will be added to a corresponding group on Tableau Server and, by the above logic, will be able to see every row of data.
Instead of performing deployments to higher environments manually, the organization required the development of an automated deployment process. This process is broken into two pieces: deployment of Tableau datasources (extracts) and deployment of Tableau workbooks.
To automate the deployment, Keyrus created python scripts that utilize the tableauserverclient library, which references the Tableau Server REST API.
The scripts perform the following actions:
Data sources:
Download the lateset version from Tableau Server based on tag
Publish to higher environment
Update the connection to reflect the Oracle db credentials of the higher environment
Refresh the extract
Workbooks
Download the latest version from Tableau Server based on tag
Change server connection of the data source (this is done using the Tableau Document API)
Publish workbook to higher environment
The Tableau Server uses SAML for Single Sign On. Oracle Access Manager (OAM) is used as the identity provider. In order for SSO to exist, the user must exist on both OAM and Tableau Server (with local authentication).
In order to automate the addition of the corresponding username to Tableau Server, Keyrus developed a python script to be triggered once a user is added to OAM with a Tableau role. The script passes the argument of the username in OAM to the Tableau Server REST API and adds the user to a group on the server with corresponding permissions to their access level.
The organization now uses self-service analytics rather than relying on static PDFs that used to require 3 full weeks of 40 hours each week to create. The new dashboard suite is immediately available and easy for users to navigate, eliminating the tedious manual work. Overall, the data process is more efficient and intuitive for users.