Flow sits in between different systems at a network, service and application level.

Very broadly, it solves for the enterprise architecture problem of applications all connecting directly to each other by operating as the hub in a hub and spoke architecture, but in nuance is often quite different to that.

Applications connecting directly

Hub and Spoke

The primary reason is that the education ecosystem has many capabilities which to solve small pieces of the overall problem; LTI, SSO provisioning etc. A real institutional system might look more like this:

Note that there are many question mark nodes, which indicate places where there are not standard solutions for integrations to or from those classes of system. These are the places which prompt custom solutions, whether those are middleware, script based or manual. Sometimes the solutions are literally reports built in Excel and imported to the target system.

These question mark points require several different solutions working in concert, providing for user experience to be delivered to a browser or mobile device, for databases to be read from and updated, and for jobs to be scheduled every day.

Flow delivers some related functionality from several of these different systems in your IT ecosystem, allowing management in one place.

It generally does not replace these systems, but overlaps and augments their behavior.

• an authenticating proxy, indirecting the end user from credentials of higher privilege in another system. For instance, an OAuth protected Web API being called for a single user session, being mediated to a payload in a backend call by a full service account to a third party system.
• an identity mediator, converting an authentication method such as CAS into another method such as SAML, or in converting SAML into SAML with a richer payload.
• a credential store, optionally storing strongly typed objects in a use but do not view configuration.
• a web server of static and dynamic content, presenting resources of any web kind; CSS, HTML, Javascript and binary files and enabling server-side processing in Javascript.
• a tunnel, so that it can interact with on-premises applications and databases as though it were inside the network.
• a key-value cache.
• a message queue.
• a scheduling engine, supporting both Cron expressions and simple interval timers.
• an SFTP browser, allowing an authorized user to act with the authority of its authorized keys.
• a request builder. Users can build SQL, HTTP and SSH requests interactively, combining them with registered credentials to test specific calls.
• a live test framework, allowing simulation of payloads through any registered processor.
• an environment manager, allowing logic to be built and tested against an institution's lower environment before upgrading locations and credentials to production.