Anthology Student consulting
Hands-on help with Anthology Student (formerly CampusNexus and CampusVue) from someone who has worked in it since 2007, first as a user and then building on it.
Student information system integration: Make your student system talk to everything else
I connect your student system to admissions, the learning platform, finance and reporting, so a change made in one place shows up in the others without anyone retyping it. Built by someone who has used these systems from the front counter.
The problem
A student information system is the system of record, but it is never the only system. Admissions has a CRM. Faculty live in the learning platform. Finance has its ledger. Each one needs to know what the others know, and when they disagree it is your staff who find out, usually from a student.
I often find this held together with scheduled batch jobs, spreadsheets and a person who remembers how it all works. That holds until a term start, a system upgrade or a resignation.
What I do
I design and build the layer that keeps those systems in step:
- Integration through the front door. Services that read from and write to the student system through its supported interfaces, never around them. I build them as REST services in C# and .NET.
- Changes that move as they happen. Serverless functions on Azure carry a change to the other systems when it is made, in place of a batch that runs later.
- Clean failure. Every message is logged, retried safely and reported when it cannot be delivered. Nothing disappears quietly.
- Integration with what you already own. Admissions and CRM, learning platforms, finance, identity, document management and reporting.
- The systems I know best. Anthology Student (formerly CampusNexus and CampusVue, now an Ellucian product) and Thesis Elements.
How I work on it
I start by reading the real system: its data, its existing integrations and the way your staff use it. That is where the surprises are, and it is cheaper to find them in week one.
Then I build in your test environment, in small steps you can see. Each step comes with evidence that it does what it should. Production changes are rehearsed first and applied by a person.
Why the result gets used
I worked in admissions, the registrar’s office and financial aid before I wrote integration code. I know which fields staff rely on, which ones they work around, and what a “small” change does to the person at the front counter. In my experience integrations fail on adoption more often than on code, and adoption is the part I am best positioned to get right.
Self-check
Is your integration ready to build?
Eight yes, no or not sure questions to answer before building an integration with a student system, each with one line on why it matters. The answers score into one of three bands, with the pages on this site that speak to the gaps. It runs in your browser and sends nothing anywhere.
Nothing leaves your browser. The scoring runs on this page, and no answer is sent or stored anywhere. These are eight general good-practice checks to answer before building an integration with a student system, not a description of any one school.
What drove this result
Show the text that will be copied
Your answers stay in this browser tab. The Copy button puts the text on your clipboard for you to paste wherever you choose, such as a message to Zak through the contact page. This page sends nothing on its own.
How the score reads
Ready
The groundwork that keeps an integration dependable is in place: you know which system is right for each field, both ends have a test environment, failures reach a named person and credentials stay out of the code. Settle each not sure before the build starts.
Worth a look
Nothing here means wait, but a few gaps tend to turn into surprises after launch. The answers listed with the result are the ones to settle first. Most close with a decision written down: which system is right, how fast a change must travel, and who is told when something fails.
At risk
Several answers, or several not sures, point at an integration that would be built before the basics are agreed. That is common when a vendor deadline arrives first, and it is fixable. Start with a read-only look at the real systems, name a system of record for each field and set up test environments before the build.
Where the fixes live
- How the integration service works: read the real system first, build in your test environment in small steps with evidence, and rehearse production changes before a person applies them.
- The near-live data sync case study: events in place of batch jobs, with messages logged, delivery that can be retried without a duplicate, and anything undelivered reported to a person.
- The managed integration hosting service: credentials kept in a vault, monitoring that alerts a person, support hours in writing, and a design that can be handed to your own team later.
Show how the score is worked out
Each question has a good answer. The other answer is the risky one and scores the question's weight: 4 foundation questions (a system of record for each field, test environments for both systems, failure handling, and credentials outside the code) score three points each, the rest score two. Not sure scores one point, and a question left blank counts as not sure. 2 points or fewer reads Ready; 3 to 7 reads Worth a look; 8 or more reads At risk, out of a possible 20. The answers that scored are listed under the result, risky answers first, then the not sures.
Common questions
Questions people ask
Can you work in our test environment first?
Yes, and I would rather not work any other way. I build in your test environment in small steps, each with evidence that it does what it should. A migration is rehearsed on a copy of your data, with a check-only run that lists what would change before anything does. Production changes are rehearsed first and applied by a person, so the real run is not the first time the work has been tried. See data migration.
We have no servers or cloud team. Can you still build us an integration?
Yes. I can host and maintain it on Microsoft Azure, in your subscription or in a dedicated environment set aside for your school. See managed integration hosting.
How do you hand over at the end, and who owns what you build?
You own everything I build for you. At handoff you get the code, the documentation, the runbooks for how it works, how to restart it and how to switch it off, the evidence from the build, and a walkthrough for your team, so another engineer can take it on. A hosted integration is defined in code with an exit plan written down, so it can move to your own team when you are ready. See security and data handling.
Other services
Reporting and dashboards
SSRS reports and Power BI dashboards your staff trust, including Crystal Reports rebuilt for the web client, by someone who has used those reports.
Data migration
Move student and financial aid data between systems with a rehearsal first and proof for every record.
Financial aid automation
Automation around financial aid data, built by a former aid administrator, with the evidence an auditor asks for.
Workflow automation
Take the manual steps out of admissions, registrar, aid and finance work with Workflow Composer and FormsBuilder, inside the system your staff already use.
Applied AI
Put AI agents to work on real operational tasks, with the controls and the audit trail a college needs.
Managed hosting
Nowhere to run an integration? I host and maintain it on Azure, in your subscription or a dedicated one.
All services
The full list, and the three ways an engagement can run.
Have a system that needs untangling?
Tell me what you run and where it hurts. The first call is 30 minutes, free, and you will leave with a clear next step whether or not we work together.