Slate has integrated successfully with a wide variety of software applications, including student information systems (SIS) such as Banner, PeopleSoft, and Colleague, as well as with business intelligence solutions and enterprise content management systems. In this article, you'll find a review of the methods and best practices for integrating external systems with Slate, along with links to relevant articles that provide more detail about each step.

Overview Demonstration of Data Integrations with Alexander

This video provides an overview of data integrations in Slate and a discussion of the tools used to share data between Slate and other systems.

Before We Begin: Data & Process Audit

As you embark on a new integration, whether a one-time migration of historical data into Slate or a bi-directional feed with a new external system, you can avoid serious headaches by engaging in a data and process audit. Much like the one we ask clients to perform at the earliest stages of an implementation, taking stock of your data, who's using it, and why will answer ahead of time a lot of the questions you might otherwise be asking when you're elbow-deep in the integration, when their cost in time and resources is much greater.

While going through the audit, it may be helpful to pose the following questions about stored data points to key stakeholders:

• Is this data point accurate?

• Is this data point necessary for us to do our job?

• Who uses this piece of information? In what capacity? 

• Is this value something that can change? Or is it purely historical?

• Why do we collect information in this manner?

Integration Considerations

Ultimately, the goal of any integration is to design a reliable, stable, supportable, and sustainable process for your institution. What does that mean exactly?

• Reliability: The integration process can be more reliable when more of it lives in the Slate infrastructure, so using the Technolutions SFTP servers is typically preferred.

• Stability: The integration process should run without constant human intervention. In other words, you should be able to “set it and forget it.” It should not need to change with any frequency. 

• Supportability and sustainability: The integration process should minimize the use of custom SQL, and value translations should be stored centrally in Slate via prompt exports or translation codes. This enables those closest to the process (like operations staff) to manage the periodic changes which may be necessary because of new terms, programs, or majors.

Best Practices

While Slate provides incredible flexibility in how data is manipulated, we strongly encourage sticking to these best practices to ensure the integration goals can be met.

• Use batched files: While Slate provides the ability to use web service calls, if it's possible to send or receive data in batches, it will always be more efficient.

• Send files overnight (2:00 AM-4:00 AM Eastern time): Slate databases have limited resources and are optimized for the speed and efficiency of the user interface. Schedule data exports and imports overnight when users are not actively interacting with the database.

• Use the Technolutions SFTP server: Send data into Slate using the /incoming folder and export data into the /outgoing folder. Using the Technolutions server allows us to provide better performance.

Pitfalls to Avoid

Your institution can choose to deviate from the best practices when there is a business need. However, some processes are explicitly discouraged as part of data integrations. The items in this list are against the intention of these features and cannot be supported by Technolutions staff:

• Don't automate the use of "Force Process Pickup" or "Force Process Import": These tools are provided to simplify the initial setup of integrations. When testing, it's much faster to make minor tweaks and force the processes. However, these are not intended to be used consistently, and doing so can have negative performance impacts.

• Don't use direct SQL access as part of an integration: The direct SQL interfaces are provided on an "as is" basis and should be used for ad-hoc reporting only. Because SQL queries built and run outside of Slate cannot be tracked or managed, even minor changes to database schemas may break some of those scripts. Direct SQL access for an organization may be discontinued at any time at the sole discretion of Technolutions if it impacts database or server performance. For additional information, refer to the article on Direct SQL Access.

Example: Integrating with an SIS

A common type of integration is between Slate and a campus SIS. Typically, applicant and financial aid data is exchanged via a transfer of flat files on a scheduled basis through an SFTP server, where the institution can dictate the specifications for the data exchange and where the value and code translations (for example, those for country codes, major codes, or term codes) happen in Slate.

The data points from Slate to the campus system typically include student biographic and demographic data, as well as key application components that are necessary outside of admissions (for example, entry term, admission plan, or admission decision). A Slate ID is also sent along with a placeholder for the Campus or Institutional ID.

A return feed is then provided, and the Slate ID is included with the matched or newly created record's Institutional ID. Subsequent data feeds from Slate into the external system, then include that identifier for direct matching.

Does Slate have an API?

There is no "preset" Slate API. Instead, Slate allows you to customize your import and export configurations specifically for your business process or integration goals:

• On import, Source Formats define the incoming data format and map the incoming values into Slate fields. You often do not need to modify the files or web service calls from external systems.

• Queries enable you to choose the relevant data fields and define the export format on export. You can essentially build an API based on the requirements of your external system.

In this way, you can import your data from various sources, and your exports can conform to the formats your external systems need. Watch our Data Integrations Overview Demonstration for more information.

Next Steps

After reviewing the overall goals, best practices, and pitfalls to avoid, you're ready to begin building your integration. 

1. The Importing Data Overview article outlines how data imports work in Slate and describes each import method.

2. The Upload Dataset article describes how data is mapped and imported once it arrives.

3. The Exporting Data Overview article describes using the Query tool to format and schedule data exports.