The article describes in conceptual terms some options for exporting data from Slate.

Before you begin

Answer these questions:

1. ⏳ 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?

2. 🪪 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.

3. 📦 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).

4. ✏️ 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.

With these questions addressed (or at least pondered about), let’s get a quick crash course in query execution properties—we’ll need to understand this terminology to consider the ways Slate addresses different data export scenarios.

The different ways queries can return records

Data exports are made with queries.

By default, when you run a query, it returns all of the records in your database that match its filter criteria.

You can change this behavior in a query’s Edit Properties menu. Here, you’ll find settings like Execution Options and Queue.

A combination of these settings gives you the following methods of query execution:

Cumulative

Everything every time.

Returns all records matching the filter criteria.

• Example: Start with 1,000 records → Since last export, add 500 → Next export includes 1,500 records

• Settings: Edit Properties → Execution Options → Retrieve all records each time query is run

Incremental

New records only.

Returns only the records matching the filter criteria that were added to the database since last execution.

• Example: Start with 1,000 records → Since last export, add 500 → Next export includes only those 500 new records

• Settings: Edit Properties → Execution Options → Retrieve only the new records since the query was last run

Differential

Updates only.

Differential queries use queues to track record changes since the last export. They return full rows each time, but only for changed (or new) records.

• Example: You start with 1,000 records → Since last export, add 100 & make updates to another 100 → Next export includes 200 records (100 new, 100 changed)

• Settings:

  • Edit Properties → Execution Options → Retrieve all records each time query is run

  • Edit Properties → Queue → Select a queue (when application is updated, when person record is updated, or when primary/secondary key is updated).

This is usually what you want for exports to an SIS.

Now that we have a sense for the ways queries can be configured for exports, lets look at the real-life scenarios to which these configurations might apply. Review the data export scenarios below and select the model that will best address the business needs of each external system.

💡 Tip

Consider the needs of each external system separately. An SIS data export is going to be different from an export to financial aid.

Send data to external system once when record meets criteria

Slate can be used as the system of record until an applicant’s status changes to Admit/Matric.

In this scenario, when an applicant becomes an Admit/Matric, Slate hands off the record information to your student information system. The SIS then becomes the system of record for all subsequent record activities and updates.

Configuring the query

Configure the data export query in Slate to be incremental; that is, select Edit Properties → Retrieve only the new records since the query was last run.

The first time the data export runs, Slate exports every record that meets the filter criteria at that time. If you have three records, A, B, and C, that meet the query’s filter criteria, they’ll all be included in the query execution:

The next time this query runs, records included in the last execution are excluded. Only new records that meet the filter criteria will be exported. If our query filters return records A, B, C, D, E, and F, only the latter three will be included in the query execution. Records A, B, and C already exist in the external system from the previous query run.

Continuously update Slate record data in external system

In some cases, when updates are made to a Slate record, those updates must be sent to an external system, for example, your financial aid system.

Option 1: Cumulative export

In this option, we configure a data export query to be cumulative; that is, we select Edit Properties → Retrieve all records each time query is run.

The first time the data export runs, every record that meets the filter criteria at that time will be exported. Here, records A, B, and C meet the criteria, and they are exported:

The next time the query is executed, every record that meets the filter criteria will be exported, even if the record was exported previously. So new additions D, E, and F are exported along with repeats A, B, and C:

Option 2: Differential (updates only) export

We might also configure our data export query to send only records meeting our filter criteria that have been updated since the last export.

We do this by selecting a queue from Edit Properties → Queue. Depending on the scope of the query, you can configure this queue to look for updates to the application, to the person record, or to a record’s primary or secondary key.

When the data export executes for the first time, all records that meet the filter criteria at that time are exported; here, records A and B meet the filter criteria and are exported.

Records that meet your filter criteria and have been updated since the last query run will be exported when the data export runs.

• A change was made to record A since this query’s last execution, so it is added to the queue.

• Record B hasn’t been changed since our last execution, so is omitted from this execution.

• Record C is a new addition, and is included in the export.

Send different data points to an external system at different times

Perhaps your process requires you to

• Hit your SIS with an initial round of Slate data

• Get an SIS ID in return

• Do some work in Slate with the SIS data

• When decision replies are received, send new information to the SIS, like updated addresses or matriculation information

In this case, we can use a combination of export types.

Working with multiple export queries

This requires that we create multiple data export queries, each of which is configured to your specifications.

In the example we’ve outlined above, the data export model would include:

• A daily, incremental export: This would include an application ID and biographical data.

• A weekly, cumulative export: This would include the application ID or SIS ID and address data.

• Another daily, incremental export: This would include the application ID or SIS ID and decision data.

Bi-directional feeds

External systems like your SIS can be configured to send data back to Slate once initial data is received.

This can be useful if important institutional data, like a Campus ID or a Student ID, is stored in Slate.

External IDs

Data sent to Slate from an external system must include a unique identifier field. We recommend the Application Slate GUID as the unique ID for returning data.

When used in Upload Dataset, this field can uniquely identify the exact application and the person record.

The Application Slate GUID is also immutable because it is a read-only field that remains intact even if the person record is merged.

💡 Tip: Need a shorter value?

The Application Slate GUID is a unique 36-character value. If an external system requires a shorter value, the Application Slate ID, a unique 9-digit value, can be used.

Option 1: 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

1. Follow steps 1, 2, and 3 above.

2. 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).

➡️Next up: Building a data export query

We’ve covered the reasons you might want a certain data export scheme over another. Now that you have an idea which you might prefer, check out the next article to learn how to build out the data export query (or queries).

➡️ Building a data export query