Sharing Slate Data: Options and Best Practices
- 15 Nov 2023
- 6 minute read
- Print
- DarkLight
- PDF
Sharing Slate Data: Options and Best Practices
- Updated 15 Nov 2023
- 6 minute read
- Print
- DarkLight
- PDF
Article Summary
Share feedback
Thanks for sharing your feedback!
Slate data may need to be shared with other parties that do not currently have access to Slate. For example, a list of admitted students may need to be forwarded to various academic departments on campus for targeted communications. Data from an inquiry pool could be delivered to a third-party vendor for analytics. External consultants may also need to see Slate data as they assist institutions in their Slate implementation or with broader admissions and enrollment efforts.
The Query Builder can export personally identifiable information, presenting a potential avenue for security concerns. Generally speaking, there are two philosophies for external constituencies accessing Slate data:
Outside of Slate - This is most commonly used with data integrations where data must be passed from one system to another. Slate supports Secure File Transfer Protocol (SFTP) to keep data protected within Slate and in transit, and is available for retrieval on the server. Slate also supports web services where data snippets can be "pushed" as a scheduled export, or "pulled" by calling a remote URL endpoint.
Within Slate - The Query Builder does not include a mechanism to email query results, since email is not a secure method of communication and could compromise student data. If users need to view a given list of records, it is advisable to grant them access to view the query directly inside of Slate. Users who are part of the institution's single sign-on (SSO) can be granted access to a specific query but not to any other areas of Slate. If the users are external to the institution's single sign-on, Slate can create external user accounts that could similarly be granted access to specific queries without broader Slate access.
No matter which approach is taken, it is important to ensure that the data is protected between Slate and the intended recipients. We recommend limiting the breadth and depth of data shared to only the most essential.
Sharing Data Outside of Slate
Exporting data and documents from the Query Builder is the preferred method for granting external constituencies access to Slate data. Data exports using the Query Builder:
Can be automated. Exports can be scheduled based on a delivery window on selected days of the week.
Are secure. Exports can be delivered to an SFTP endpoint (Technolutions servers or a remote SFTP server) and can be encrypted.
Can be delivered as a web service where data can be fetched from a Slate endpoint in XML or JSON format. The web service can be secured behind basic password authentication.
There are situations when exporting a data feed is not desirable. The sections below describe other options to share Slate data.
Sharing Data Within Slate
If the user also has an institutional login, a new user account can be created for them in Slate, with access limited to what they need to view.
However, if they do not have an institutional login, an "external user" account can be created.
Select Database on the top navigation bar and select User Permissions.
Select New User. Enter user account details such as first name, last name, etc.
Under the "security" section, set user type to User (External). A regular "user" is someone who uses the institution's authentication (SSO), whereas "User (External)" uses Slate authentication.
Assign a new user ID and password. Select the option for Active: Enable account for access.
If login is used to only view Slate data, do not grant the user account any permissions.
Note the link for External Login URL:
The Slate domain + /manage/login/external
For example, https://admissions.slateuniversity.edu/manage/login/external
Important
Since external users must use a different link from the regular Slate instance login, they must enter the user ID and password assigned to the external user account. Be sure to provide them the external login URL. They also need the URL of the query.
Can external users ever be granted permissions?
Yes, if they are required to perform other tasks with Slate data and records. An example of a different need for creating external users is allowing external application reviewers access to the Reader.
Use Roles to Manage Permissions for Shared Queries
Select Database on the top navigation bar and select User Permissions.
Select Edit User.
Select the Roles tab.
Select a Role for the account (a user may also be assigned multiple roles).
Select Save.
A role can then be granted permission to a query or report.
Select Queries / Reports on the top navigation bar.
Select Edit Query.
Select Sharing Permissions, and select Add Grantee.
Set to Active.
Under Type, select Role, and then select the specific role that may access the query using the external login.
For additional information on creating users and roles, review the Users, Permissions & Security article.
Access a Shared Query as an External User
Log in through the External Login URL: (for example, https://admissions.slateuniversity.edu/manage/login/external), using the user ID and password established for the external user account.
Open the specific query to which access has been granted.
Select Run Query to generate query results.
Instruct the user to "pin" the query to their query list for ease of navigation. Otherwise, they must have the URL for the query each time to access it, due to security restrictions.
Query Permissions
If the user has not been granted any permissions, they will not be able to edit the shared query. If the user account is given the "Query" permission, they will be able to edit the query by adding local filters and exports.
The "Query" permission also opens limited access to Query Builder. In addition to being able to edit the query to which they have access, external users can see a list of queries that are marked Share query with other users with the query and query base permissions. However, upon attempting to open other queries to which they have not been explicitly granted access, they will encounter a 403 error.
If the account is given the "Query (Slate Template Library)" permission, they will also be able to use exports and filters from the Slate Template Library in the query.
Query Output Options
When the external user runs the query, they also have access to the output options available from the query results page.
Export Destinations | Batch Management |
|---|---|
Excel Spreadsheet | Field |
Deliver Mailing | Generate PIN |
Report Builder | Interaction |
Comma-Delimited CSV File | Retroactive Refresh |
Tab-Delimited File | Tag |
PDF Report | Activity (Applications query population) |
HTML Report | Bin (Applications query population) |
Mail Merge Word Document | Checklist (Applications query population) |
PDF Document Export (Applications query population) | Decision (Applications query population) |
Decision Letter Export to Word (Applications query population) |
|
There are a few other output options available with other query populations, e.g. Priority, Form/Event update.
The Batch Management options and the Deliver Mailing and Report Builder destinations will not function for external users, provided they do not have the following permissions:
Deliver - Deliver Mailing
Query - Report Builder
Person Update - Field, Generate PIN, Interaction, Retroactive Refresh, Tag
App Update - Activity, Checklist
App Decide - Decision
Bin Management - Bin
Important
The PDF Document Export as well as Decision Letter Export to Word output options are available with an Applications query population. The PDF document export generates a document containing materials as defined by the Admin PDF Download configuration, or by default, the dashboard, application, comments, references, school reports, and transcripts associated with the application record.
Exercise caution when creating shared queries for external access.
If the external user needs a list of records every week, is there a way to automate the query?
The only way to automate a query run is with a scheduled export, which is a data export feature as described earlier in this article. An external user with access to a Slate query must run it every week if they need to pull data on a weekly basis.
Best Practice
If the external users need to view data and also send updates back into Slate, consider handling this process with data integration or portals instead.
Was this article helpful?
