Third party sponsorship is not one step. It is a chain of decisions that has to land cleanly in the tuition record.
For many UK and European institutions, a student being funded by an external organization is not an edge case. It is a normal part of how tuition gets paid. But operationally, it sits right at the intersection of student data, finance, approvals, evidence, and policy. A student needs a clear way to declare a sponsor and provide proof. Staff need enough context to make a decision without chasing details. And the system needs to update the student record correctly, without shortcuts or assumptions.
That balance becomes even more important in Ellucian SaaS. The move away from on-premises systems changes how institutions handle processes that were once supported by local scripts, direct database access, or informal coordination between teams. In SaaS, those patterns no longer apply. Instead, the process has to be explicit, API-driven, and reliable for every institution that adopts it.
Ellucian invests in reusable, SaaS-ready solutions tailored for the UK higher education context. These efforts focus on turning familiar institutional processes into standard building blocks, combining workflows, integrations, and Experience components that institutions can adopt rather than rebuild. Ellucian trusts ABCloudz to deliver a number of these designs, and the third-party sponsorship workflow is one of them.
In this post, we walk through a reference architecture for handling third-party sponsorship cleanly in Ellucian SaaS. It combines Experience components for student entry with Intelligent Processes for orchestration and standard APIs for controlled updates back to Banner SaaS.
Focused on something else at the moment?
As an Ellucian Services Partner, ABCloudz works across many other Ellucian projects and a wide set of higher education projects.
The situation we started with
Third party sponsorship usually appears at one of two moments. Either during enrolment, or later when a student needs to declare a sponsor mid-course. Different entry points, same requirement. The sponsorship still has to be reviewed, approved, and recorded correctly.
The complexity comes from how the information is split. Some data already exists in Banner. Some only the student can provide. Some must match an existing non-person sponsor. And none of it should trigger financial updates until staff review the evidence.
There is also a critical financial nuance. Adding a student to a third-party contract does not always mean that contract is ready to pay. Authorization can depend on further checks, and the workflow has to respect that boundary instead of skipping it.
Institutions needed a clean way to collect sponsorship details, support proper approval, and update Banner SaaS without assumptions or shortcuts. That missing structure is exactly what this workflow was built to provide.
Building the workflow in Ellucian SaaS
Although we describe this as a workflow, the design is intentionally a reference architecture that splits responsibilities across standard Ellucian SaaS components. Experience and Forms handle student entry and evidence capture, Intelligent Processes orchestrates review and decisions, and Business APIs apply controlled updates to Banner SaaS as the system of record.
Two entry points, one path
The process starts where students already are, through Experience entry points. If a sponsor is declared during enrolment, the process is triggered automatically to collect the missing sponsorship details. If the declaration happens later, the student enters through a dedicated workflow form. Different entry points, same downstream path.
Collect what matters, pre-fill the rest
From there, the form does the heavy lifting. It pre-fills what the system already knows, such as student identity, programme, term context, and contact details. The student focuses only on what they actually need to provide. Sponsor name and contact details, sponsorship duration, percentage or amount covered, and supporting evidence. Where possible, sponsors are selected as existing non-person entities rather than free text, keeping data clean and consistent.
Evidence stays where it belongs
Supporting documents are treated as first-class citizens. Evidence is attached through the institution’s document management setup, with the design accounting for both Banner Document Management and Ellucian Document Management. The workflow does not assume which one an institution uses, and it does not bury documents inside the form itself.
Clear approvals, no side paths
Once submitted, orchestration shifts from collection to decision. Intelligent Processes routes the request to the appropriate approval group, maintained by the institution. Approvers see the full context in one place and choose a clear outcome. Approve or reject, with comments captured as part of the record. No side emails, no guesswork.
Approval without shortcuts
Rejection is handled cleanly. The student is notified, and supporting documents can be removed where required. Approval moves the process forward, but without cutting corners. The workflow adds the student to the appropriate third-party contract in Banner SaaS, using standard APIs and respecting financial rules. Authorization is applied only when it should be. If further checks are needed, the contract can exist without being authorized to pay until those checks are complete.
A deliberate boundary
One boundary is intentional. If no third-party contract exists yet, the workflow does not try to create one automatically. Setting up a contract requires information the student cannot provide and usually involves direct coordination with the sponsor. The workflow surfaces the situation, but leaves contract creation as a controlled, manual step.
Results
The result is a SaaS-native process built entirely from standard Ellucian components.
Students get a clear path to declare a sponsor, attach evidence, and know their request did not vanish into the void. They receive a submission receipt, then a clean outcome message once staff decide.
Staff get a decision-ready case, not a scavenger hunt. The request arrives with student context, sponsor details, evidence, and a single place to record comments and choose approve or reject. That keeps the review focused on the decision, not on tracking down missing pieces.
Institutions get a reusable SaaS workflow that respects financial boundaries instead of skipping them. Approved requests update Banner SaaS through standard APIs, and authorization can be applied only when it should be.
For Ellucian, it adds another reusable SaaS reference architecture building block for the UK higher education context. It turns a common institutional need into a supportable approach that institutions can adopt and reuse without rebuilding the process from scratch.
Building workflows that feel native in Ellucian SaaS
That is the kind of work we do with Ellucian and with institutions adopting Ellucian SaaS. We map the real process first, including the parts that should not be automated, then design a workflow that uses standard SaaS components to carry the load. Experience and Forms for the student-facing entry, Intelligent Processes for orchestration and decisions, and APIs for controlled updates back to the system of record.
If you are standardizing a sponsorship process in Ellucian SaaS, we would love to help. Contact ABCloudz and tell us what you want to standardize in Ellucian SaaS.