Why Path Portal
Modern, mobile, easy-to-use
Path (at the time Campus) was initially introduced to Salve Regina University (SRU) as a replacement for their older portal. They were looking for something more modern. They wanted a mobile-friendly application and an easy-to-use interface.
Path met their requirements.
We were in the market for a new portal, so we started investigating our different options, and we came across Path. It was very impressive: the nice modern feel, the amount of integration and especially the mobile-native functionality.
– Christine Dumont, Enterprise Apps
“We went live with Path in July after purchasing it in May. During the implementation, we used their product called Flow. Flow was able to take data from our Canvas LMS system and present it as a widget for our course information for faculty and students. It also took data from Colleague, our student information system.
“Path used our demographic data in order to personalize the interface and organize students and staff into specific groups that make sense to them. Flow is something that was running in the background and allowed us to have more flexibility within our portal tool.”
As Christine’s team used Flow, they began to dream up other uses for the tool. In particular, they thought of the clunky, inefficient processes they used to cobble together reports.
The Next Phase
Enterprise data warehouse
“We have some applications that are in the cloud and some that are on-prem. Right now, we use a variety of methods to move the data from one place to another. Several, thankfully use TCP/IP, but others are just plain manual.”
Christine outlined a particularly painful process they use to get a strategic report on graduate studies data.
“We have a transaction that happens in Slate CRM. We move that into our Colleague database and then pipe that out to another data store. Then we run a report and then that data gets manipulated by pivot tables until it’s finally displayed in Tableau.
“I bet everybody’s thinking the same thing: that’s incredibly inefficient. We recognize that as well.”
Christine used a fantastic analogy for the typical higher education technology infrastructure. Instead of a wheel with a central source of truth with spokes leading to different data sources, the map would look more like a spider web.
Systems are sometimes tightly integrated, but most of the time, there are one-off connections and file transfers that take place via email or FTP connections or some other unique process.
The goal of our enterprise data warehouse is to expand the number of integrated systems using Flow and put that data into a central data warehouse so that we can have better more robust strategic reports.
– Christine Dumont, Enterprise Apps
“What we want to do is have something that’s streamlined so that we can take all of the systems of record, whether that be our Colleague student information system, our CRM, or Canvas–any sort of data that could exist in our spider web technology stack–and then bring it into a staging area where we can transform it using logic before it gets loaded into a nice, clean enterprise data warehouse that would then be reliable for business intelligence and analytic reporting.”
To transport the data and make changes along the way, SRU is leveraging Flows.
How flows solve merging data sources & much more
Flow is more than classical middleware. What “classical middleware” sits somewhere in the center of a number of interacting applications and it has the responsibility of keeping any two systems from being dependent on one another’s exact configuration. Sometimes middleware strictly busses information from one location to another, while at other times it caches the data and retains it.
We all have felt the pain of hearing the marketing team come up with a great idea (which involves another cloud application) and realizing we have to change everything upstream and downstream to make sure the systems continue to play nicely together.
When you have a spider web of dozens and dozens of enterprise applications, the permutations of change mean that your entire ecosystem as a whole is always in flux. Middleware makes it so when one system’s configuration changes or a system is added, the only thing that is altered is its relationship to the middleware.
We should mention that for every rule, there are exceptions. There are integration protocols, such as LTI, which means that two systems are natively very closely coupled together at a presentation and view layer. There are systems, such as OAuth protected systems, where the user is actually going to make a call from the browser to bring data in and there won’t be a system in the way. So your Microsoft calendars, your Google documents, your Canvas or Moodle or Blackboard may very well have an LTI integration with OAuth in play.
A conventional middleware has no relationship to these exceptions (for example, LTI Integrations or OAuth). Path and Flow operate a bit differently while remaining entirely cognizant of the necessity of airtight data security.
We used to block users based on whether or not they were physically connecting to routers on campus. Post global pandemic, we can’t say that anymore. The student portal often finds itself occupying a position of gating access to other systems. Although Path is not an identity provider and Flow is not an identity provider, we have several contexts in which we perform an identity mediation function, which is to say that a log-in occurs directly in Flow, not the gated system. Flow actually enriches the payload and adds information about the user.
This is a vastly more efficient pattern. Rather than two systems back behind a wall exchanging database information, now it can just be done on demand. Authentication is treated as if it were just another integration step to be enriched and to be enhanced. In this manner, Flow is an application server, and it serves the function of standing as a web listener. It enables requests to be served. It enables resources to be loaded onto it.
Flow sits in a position in your ecosystem that:
Flow safeguards your precious database credentials and API keys and then provides trusted access to back systems.
We mentioned that endemic to our industry are things like proprietary systems (and data structure and “magical string codes”). We know that human interpretation problems are usually the most fallible part of a processing system, but we also know that they’re one of the most flexible. They’re there for a reason because you cannot anticipate everything upfront, and all of the data can’t be naturally represented.
At this point, Flow has, like arrows in its quiver, some 220 distinct integrations across educational systems. The knowledge and patterns gained from those are available to Flow partners as a playbook. They’re not necessarily something that you would grab and just plugin, but they are something that you will adopt and adapt. We think that the right way to approach the flexibility required for a tertiary ecosystem is to present a pro forma use case and say, “This is how it tends to be,” and then tweak and refine for your particular use case.
Does this sound overwhelming? This is a complex problem, and the answer is, by necessity, comprehensive. However, as we always say, you don’t need to do any of this alone. At Path, we pride ourselves on our excellent partner support.