Boston University recently implemented Technolutions Slate for graduate admissions, while PeopleSoft Campus Solutions (CS) continues to serve as the system of record. As we worked through the integration, we found that the challenge was about much more than moving data between two systems. Some of the most important decisions involved system ownership, transaction management, error handling, and long-term supportability.
In this article, I wanted to share a few lessons from our implementation that may be helpful to other institutions connecting Slate, Campus Solutions, or similar CRM-to-SIS platforms.
A consolidated view of the integration
|
SLATE
Recruiting
Applicant portal
Applications & decisions
|
→
|
MIDDLEWARE
Stage • Validate • Transform
Route • Monitor • Reconcile
|
→
|
CAMPUS SOLUTIONS
System of record
Student & application data
|
|
← IDs, statuses and reconciliation information return through the same broker ←
|
|
Transaction lifecycle: STAGED → PROCESSING → COMPLETED
Transient technical failure: controlled retry | Data/business issue: HELD for review
|
Figure 1. High-level integration and transaction-processing model.
At a high level, Slate sends application data through the middleware to Campus Solutions. The middleware stages, validates, transforms, routes, and monitors the transactions. Information such as university IDs and statuses can then flow back through the middleware to Slate for reconciliation.
1. Define clear system ownership
One of the first things we established was a clear boundary between the systems. Slate manages the admissions experience, Campus Solutions remains the institutional system of record, and middleware brokers the exchange between them.
Having that ownership defined early helped us avoid creating multiple independent point-to-point integrations.
2. Stage before processing
Incoming application transactions are staged before they are transformed and submitted to Campus Solutions.
This gives us a durable processing history, a clear recovery point, and, most importantly, visibility. When someone asks, “Where is this application right now?” we have a place to start.
3. Treat failures differently
One of our most important lessons was that not every failure should be retried.
Temporary technical issues, such as timeouts or connectivity problems, may be safe to retry. Data or business-rule issues are different and should be held for review.
Making that distinction helps reduce the risk of duplicate or inconsistent application records and gives us better control over recovery.
4. Use delivered functionality where it fits
For application creation, our integration uses delivered Campus Solutions application creation and submission capabilities, while our institutional identity process handles Search/Match and university ID creation.
The middleware orchestrates the transaction rather than rebuilding functionality that already exists within Campus Solutions.
For us, the lesson was simple: use delivered functionality where it makes sense and customize only where there is a clear institutional need.
5. Close the loop
The integration does not end when an application reaches Campus Solutions.
University IDs and other appropriate lifecycle information are returned to Slate through the middleware, helping with reconciliation and keeping the two systems aligned.
Having middleware broker communication in both directions also gives us a consistent place for monitoring and troubleshooting.
6. Choose the simplest pattern that fits
Not every integration needs the same architecture.
Transactional application processing benefits from middleware and APIs, while other flows—such as tuition-deposit processing—can be handled effectively through a controlled file-based integration.
The key lesson for us was to let the business requirement determine the integration pattern, rather than choosing a technology first.
Key takeaways
- Define system ownership before designing the interfaces.
- Stage transactions to improve visibility, auditability, and recovery.
- Separate retryable technical failures from data issues that require review.
- Use middleware as a consistent broker for transactional integrations.
- Use delivered Campus Solutions functionality where it meets the requirement.
- Design monitoring and reconciliation from the beginning, not as an afterthought.
Final thoughts
Our biggest takeaway was that successful integration architecture is less about moving fields and more about managing ownership, state, and failure.
Designing those concepts into the solution from the beginning has made the integration easier to understand, operate, troubleshoot, and support.
For those who have implemented Slate with Campus Solutions—or a similar CRM-to-SIS integration—I’d be interested in hearing about your experience.
What integration patterns worked well for your institution? What lessons did you learn, and what would you approach differently if you were starting again?