Data exports serve as a crucial conduit for transferring information from Slate to external systems such as Student Information Systems (SIS), Financial Aid Systems, and more. Whether you need to initiate essential business processes or maintain smooth operations across multiple platforms, data exports bridge the gap, enabling seamless exchange of data and ensuring operational continuity. 

Improve your understanding and success with this process by:

• Utilizing the Power of Query Builder: The Query Builder is a powerful tool used to create and manage data exports, ensuring that query data is executed and delivered in the desired format. Explore Query Builder articles for insights into reformatting data and using value translations.

• Configuring Data Exports in Slate: Before diving into export settings, ensure you have gone live with Slate and established custom fields, prompts, and existing record data. This approach aligns the export structure with Slate's processes, facilitating a smooth flow of data and optimizing the export functionality.

• Customizing Exports to Meet Your Needs: Each institution has unique requirements for data exports. Gain proficiency in editing and creating tailored exports that allow you to extract data in the precise format required for your external systems.

Slate is very flexible when it comes to data exports, which are structured around how your data is stored in Slate. Data exports should be configured after going live with some or all aspects of Slate, such as custom fields and prompts or existing record data. It is best to structure data around Slate processes – not that of the export destination. 

You will better understand the data export process and receive a practical example of an export. You will gain proficiency in editing and creating customized exports to meet your specific requirements.

Partners frequently need to export data from Slate to external systems, such as a Student Information System (SIS) or a Financial Aid System, to begin or proceed with a business process. This typically happens at the applicant stage, and exports often contain applicant and financial aid data.

Most institutions export data to their SIS via flat files on a scheduled basis. Data exports are created and managed via the Query Builder tool, where an export of the query data can be run in the desired format. 

Getting Started

There are various options and strategies to consider when building a data export in Slate. Therefore, it is essential to define the use for a data export before making any actual configurations.

Before building a data export, answer these critical questions:

When does data need to exist in the external system?

Consider the business processes dependent on data in an external system. For example, do data points need to exist in a SIS or Financial Aid System at a certain point to accomplish institutional work?

What data needs to exist in Slate before the record is included in an export?

An external system can require specific data points to be populated to import successfully.

What data points in Slate are needed in the export?

An efficient data export will include only the data points necessary for institutional business processes (for example, the meal choice a prospective student selected for a campus visit is likely optional).

A unique Slate ID (such as Application GUID) will be required to ensure a positive match when sending data back into Slate through an import if configuring a bi-directional data feed (see Bi-Directional Feeds below for more information). 

How does the data need to be entered into the external system?

An external system might not be as flexible as Slate. Configuring value translations, maximum field lengths, or special formatting for specific data points in the export might be necessary.

Data Export Scenario A

When a record meets specific criteria, send data to an external system once.

Slate can be used as the system of record until an applicant becomes an Admit/Matric. When an applicant becomes an Admit/Matric, the record information can be sent to a student information system. The SIS then becomes the system of record for all subsequent record activities and updates.

Incremental Data Export File
Configure one data export file to send data to the external system for each record once. For example, the first time the data export runs, every record that meets the filter criteria at that time will be exported:

The next time the data export query runs, previously exported records will be excluded. Only new records that meet the filter criteria will be exported:

Remember: Records A, B, and C already exist in the external system from the previous query run.

Data Export Scenario B

Record data should be continually updated in an external system.

If updates are made to the record in Slate, those updates must be sent to an external system (for example, PowerFAIDS). 

Option A: Cumulative Data Export File

One option is to configure one data export file to send every record that meets the filter criteria every time the data export runs.

For example, the first time the data export runs, every record that meets the filter criteria at that time will be exported:

The next time the data export runs, every record that meets the filter criteria will be exported, even if the record was exported previously:

Option B: “Updates Only” Data Export File

Another option is to configure one data export file to send only updated records that meet the filter criteria every time the data export runs.

When the data export runs before the queue has been configured, all records that meet the filter criteria at that time will be exported:

• Records A and B met the filter criteria when the data export ran.

Once the queue is configured, records that meet the filter criteria and have been updated since the last query run will be exported when the data export runs:

• Records A and C met the filter criteria and were updated since the last time the query ran.

Data Export Scenario C

Send different data points to an external system at different times.

For example, if record information needs to be sent from Slate to a student information system to generate an SIS ID and support business processes that rely on SIS data, send any updated addresses throughout the year and matriculation information to an SIS when decision replies are received.

Use a Combination of Export Types

Configure multiple data export queries. Each separate data export can be configured according to specifications.

For example, in the scenario example above, the data export model might look like this:

Data Export Query

Suitcase: Model Data Export Query 

This query contains the most commonly used standard exports for most application data exports.

1. Expand Queries. 

2. Click Queries / Reports in the top navigation bar.

3. Whether you create a new query, open an existing query, or use the suitcase example provided above, follow the instructions in the sections below to configure the query according to the external system requirements.

Bi-Directional Feeds

If the external system sends data back to Slate, a unique identifier field must be included in the data export.

The Application Slate GUID is the recommended unique ID. When used in Upload Dataset, this field can uniquely identify the exact application and the person record. The Application Slate GUID is also immutable since it is a read-only field that remains intact even if the person record is merged.

Option A - Single Data Export File

1. The external system ID field (like SIS ID) is included as an export. This field will typically be blank for the initial data export. The lack of the external system ID field in the file can initiate record creation in an external system.

2. When the Slate record enters an external system for the first time, the external system will store the Application Slate GUID and assign a system ID.

3. Including the Application Slate GUID in a subsequent import into Slate ensures that a precise match is made with the Slate application.

Include the externally assigned system ID field in this file and map it to a unique custom field in Slate.

4. The presence of the external system ID in the file allows the external system to match the data onto the existing record in the external system.

Option B - Multiple Data Export Files

An initial data export file follows steps 1, 2, and 3 above.

4. Additional data export queries use the Field Value Exists filter to only send data for records with an ID assigned (for example, the record already exists in the external system). See the following section for additional filter information.

Add Filters to Restrict Results

Add filters to define the population that should be included in the data export. This filter configuration will restrict the query results to only include applications in the Active Application Period with a confirmed Admit decision.

Add Literals

Your title goes here

If every record needs the same static value in a certain column, add a literal as an export. Click the Literal button to add a fixed value as an export column. Every row in the query results will have the configured value in this column.

• Name - Provide a name for this export.

• Literal - Configure the value appearing in this export column for every record in the query results. In the example above, every record that meets the filter criteria will have the value MA in the Address Code column.

Edit Exports

Hover over any export box. Click the Edit icon or double-click to edit the export configuration.

• Alter the display name (the column name) of the export.

• Width - Set the width of an export column for fixed-width exports or to truncate a value at a certain length.

• Format Type - Select a format type to enable a format mask.

• Format Mask - Enter the format mask that should be used to format the display of the value.

Edit exports that require value translations.

• Export Value - Configure prompt lists to have export values to perform value translations for prompts.

• All/One? - For exports that contain multiple values, define how those values should be exported.

• Separator - When exporting multiple values, configure the separator that the external system expects (A,B,C). This setting can be left blank if a system does not require a separator (ABC).

• Null Value - Configure the value to be exported if a value does not exist for a record (as needed).

Remove Exports

Add Exports

Order Exports

Edit Properties

Click Edit Properties to configure the query to execute according to the data export model.

Select the Execution Option for the data export query:

• Retrieve all records each time query is run: This option can be selected for cumulative or queue/"update only" exports. All records that meet the query criteria will be included in the query results each time the query runs.

• Retrieve all and save result history: This is another option for cumulative exports. All records that meet the filter criteria will be included in the query results each time the query runs. Additionally, query results' history is saved for one year, so the records that met the filter criteria for previous query executions are viewable.

• Retrieve only the new records since the query was last run: This option is used for incremental exports. When the query is run, only records not included in any previous results for the query will be exported. The history of the query results are saved.

“Update Only” Exports using the Update Queue

• Slate provides three different types of update queues. Each is specific to a population/query base. 

  • Person Update: Returns records where the person record* has been updated since the last time the query ran. Use this option only with the Prospect population/query base queries (one row per person.)

  • Application Update: Returns records where the application record* has been updated since the last time the query ran. Use this option only with the Application population/query base queries (one row per application.)

  • Decision Update: Return records where the decision record* has been updated since the last time the query ran. Use this option only with the Decision population/query base queries (one row per decision.)
    * Inserts, updates and deletes to decision, school and address records are considered as updates to both person and application records. Person updates also trigger an application update.

• Be sure to select the correct Queue. The selected Update Queue must match the query base to avoid erroneous results.

• When using an update queue, it is necessary to use the "Retrieve all records each time the query is run" execution option.

• This type of export will only return new and updated records. Therefore, running an initial export of all records before configuring the Queue setting is essential, and sending this initial file to your external system. 

• Updated records will not appear in query results immediately when using the Queue options. When a record is updated, it is flagged and added to the Deferred Update Queue (as is done with rules). When rules run, all records in this queue are added to any Update Queue queries. 
  As a result, you might have to wait up to 15 minutes for the updated records to display in query results. Please keep this in mind for testing. 

• Integration consideration: When using this type of export for the SIS, consider changing the Disable Update Queue setting on SIS import source formats to "Prevent records from entering update queue upon import." This helps prevent records from being constantly put back in the queue.

Exporting Data with Web Services

This article details how Slate supports the ability to create custom web services using the Query Builder. Any query can be routinely called as a web service or scheduled to push data into another system.