There may be times when you need to share Slate data with a third party that doesn’t have Slate access.

For example, you might want to:

• Share a list of admitted students with academic departments on campus

• Send data from an inquiry pool to a third-party vendor for analysis

• Send data to external consultants as part of your implementation

There are two ways to share Slate data safely with third parties:

• sending the data outside of Slate (recommended)

• bringing the third party inside Slate

Sharing Data Outside of Slate

We don’t recommend sharing query results with third parties because they may contain personally identifiable information (PII).

Instead, we recommend one of the two secure methods for exporting data out of Slate: via the Secure File Transfer Protocol or with web services.

Secure File Transfer Protocol

Slate supports Secure File Transfer Protocol (SFTP) to keep data protected within Slate and in transit.

For more information, explore our SFTP documentation.

Web Services

Slate also supports web services. Web services push data snippets as a scheduled export. They can also pull them by calling a remote URL endpoint. For more information, check out our web services documentation.

Benefits to using SFTP or web services

• 🕑 Automated: Both of these options can be automated to send within a delivery window on days of the week that you choose.

• 🔒 Secure: SFTP and web services are much more secure than email. Exports can be delivered to an SFTP endpoint (either Technolutions servers, or a remote SFTP server) and can be encrypted.

• 🧩 Configurable: 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.

Sharing Data Within Slate

While exporting data using SFTP or web services are our recommended best practices, exporting a data feed isn’t always desirable. In these cases, you’ll bring the third party inside your Slate database.

Internal users

Single sign-on (SSO) user access in Slate is incredibly granular. For example, an SSO user can be granted access to a single query and nothing else.

Queries don’t let you directly email results because email is not a secure method of communication and could compromise student data. If users need to view a given list of records, grant them access to view the query directly inside of Slate.

📖 Further reading

To learn more about internal user access, check out our Users & Permissions documentation.

External users

Slate can also create external user accounts that can be granted access to specific queries, without broader Slate access. The remainder of this article covers external user creation and permissioning.

Limit the breadth and depth of data shared with external users to only the most essential.

Creating an external user account

Regular users use your institution's authentication (SSO). In the User Permissions tool, you can create a user with a User (External) setting. This setting prompts these users to uses Slate authentication.

To create a user account for an external user:

1. From the main navigation, select Database.

2. Select User Permissions.

3. Select New User. A popup appears.

4. Configure the following settings:

   • Enter personal information, such as first name and last name.

   • User Type: User (External)

   • User ID: Create a user ID.

   • Activation Password: Create an activation password for the external user.

   • Active: Select Enable account for access.

5. Configure other settings as necessary. See Adding a User for more details.

6. Click Save.

🔗 External login URL

The external login URL is <YOUR SLATE DOMAIN>/manage/login/external.

For example, https://admissions.slateuniversity.edu/manage/login/external.

When external users arrive at this URL, they must enter the user ID and password assigned to the external user account.

Granting external users permissions

👁️ If the external user only needs to view Slate data, do not grant their account any permissions.

✏️ If the external user needs to perform other tasks with Slate data and records, grant them additional permissions. For example, you might allow external application reviewers access to the Reader.

To grant an external user account permissions, you first need to grant them a role. That role can then be given permissions.

You must configure a role for external users before completing the next steps. See Roles for more information.

To grant an external user permissions:

1. From the main navigation, select Database.

2. Select User Permissions.

3. Select Edit User.

4. Select the Roles tab.

5. Select a Role for the account (a user may also be assigned multiple roles).

6. Select Save.

To add access to a given query to the role:

1. Select Queries / Reports on the top navigation bar.

2. Select Edit Query.

3. Select Sharing Permissions, and select Add Grantee. 

4. Set to Active.

5. Under Type, select Role.

6. Select the specific role that may access the query using the external login.

🔓 Granting external users permission to edit queries

External users can’t edit shared queries without the Query permission. The Query permission lets them add local filters and exports.

The Query permission also opens limited access to Query Builder. External users can see a list of queries marked Share query with other users with the query and query base permissions. External users attempting to open queries for which they do not have explicit access encounter a 403 error.

Accessing a shared query as an external user

For an external users can see the query to which they’ve been granted access, they must:

1. Go to the External Login URL. For example, https://admissions.slateuniversity.edu/manage/login/external.

2. Enter their user ID and password established for the external user account.

3. Open the specific query to which access has been granted.

4. Select Run Query to generate query results.

To avoid having to re-enter this URL every time, instruct external users to pin the query for ease of navigation.

Query output options

When the external user runs a query, they also have access to the output options available from the query results page.

Output options include:

↗️ Export Destinations

• 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)

⚙️ Batch Management

• Field

• Generate PIN

• Interaction

• Retroactive Refresh

• Tag

• Activity (Applications query population)

• Bin (Applications query population)

• Checklist (Applications query population)

• Decision (Applications query population)

There are a few other output options available with other query populations. For example: Priority, or Form/Event update.

Batch Management options and the Deliver Mailing and Report Builder destinations will not function for external users by default. To enable these options, grant one (or a combination of) 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

The PDF Document Export and 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. 

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.