One Student, Two Systems: How EduSight and Salesforce Finally Talk to Each Other
Ask any admissions counselor what slows them down, and you'll hear some version of the same story. A prospective student chats with the AI assistant at 11 p.m., asks three sharp questions about the nursing program, and drops off. By the time the counselor logs into Salesforce the next morning, none of that shows up. The lead looks cold. The counselor calls anyway, working from a blank slate, and the student can tell.
That gap, between where student engagement actually happens and where admissions teams actually work, is the reason EduSight built a native Salesforce integration. Not a one-time data dump. Not a CSV someone uploads every Friday. A real sync, running in the background, keeping both systems honest about what's actually going on with a student.
Why one-way sync isn't always the answer
Most integrations are built around a single assumption: data flows from the "smart" system to the "system of record." For a lot of vendors, that's the whole feature. EduSight took a different approach, because in practice, universities don't all want the same thing.
Some institutions want a strict one-way flow. Their Salesforce instance is the single source of truth, shaped by years of admissions process design, validation rules, and reporting built around it. They want EduSight's engagement data (chat transcripts, program interest signals, response times, sentiment) to land in Salesforce, but they don't want anything written back into EduSight from the CRM side. That's unidirectional sync, and it's the right call when governance matters more than convenience.
Other institutions run it the other way: counselor notes, stage changes, and lifecycle updates made in Salesforce should immediately reflect inside EduSight, so the AI assistant never gives a student outdated information about where their application stands. That's also unidirectional, just pointed the other direction.
And a growing number of schools want both. A change in either system should show up in the other, automatically, without someone playing translator. That's bidirectional sync, and it's the configuration we see most often once a university has lived with the integration for a semester or two.
EduSight supports all three patterns, and which one you use isn't a one-time decision baked into the product. It's a setting.
A field is a field, whether Salesforce built it or you did
Here's where a lot of integrations quietly fall short: they sync the obvious stuff (Lead, Contact, Opportunity) and stop there. That works fine until you remember that no two admissions offices run on the same Salesforce instance. Every school we've worked with has customized theirs. First-generation student flags. Test-optional status. Visa type for international applicants. Program-of-interest picklists specific to their catalog. None of that is standard, and none of it is optional if you actually want a complete student record.
EduSight's field mapping isn't hardcoded to Salesforce's out-of-the-box schema. Standard fields sync the way you'd expect: Lead status, Contact details, Opportunity stage, Campaign membership. Custom fields sync the same way, because from EduSight's side, a custom field an admissions team built three years ago looks exactly like any other field: something with a name, a type, and a place to go. You map it once in the sync configuration, and it behaves like it's always been part of the integration.
A large public university: engagement data that actually reaches the counselor
Picture a state university system fielding tens of thousands of inquiries a year across a dozen programs. Their admissions team lives in Salesforce: it's where territories are assigned, where SLAs are tracked, where leadership pulls funnel reports. EduSight's chat assistant, meanwhile, is often a prospective student's first real touchpoint, answering questions about transfer credits and financial aid at whatever hour they happen to be awake.
Before the integration, that first conversation lived in EduSight and nowhere else. A counselor working a lead in Salesforce had no idea the student had already asked about the RN-to-BSN track, twice, and seemed hesitant about cost. With bidirectional sync turned on, that changes. Every meaningful interaction (the questions asked, the program interest expressed, an engagement score reflecting how warm the lead really is) flows into custom fields on the Salesforce Lead record. The counselor opens the record and already knows what the student cares about. When the counselor updates the stage to "Application Started" in Salesforce, that status flows back into EduSight, so the next time the student opens chat, the assistant doesn't ask them to re-explain where they left off.
Nothing about the counselor's workflow changed. They still live in Salesforce all day. What changed is that Salesforce stopped being half the picture.
A private college: choosing unidirectional on purpose
Not every school wants that much back-and-forth, and that's a legitimate choice, not a limitation. A mid-sized private college we've talked to runs a lean admissions office with a Salesforce instance that's been carefully locked down: validation rules, required fields, approval processes, the works. Their compliance office is understandably cautious about any external system writing into it, let alone reading from it and writing back.
For them, EduSight is configured strictly one-way: engagement data flows out of EduSight and into Salesforce as new custom fields on the Contact object, things like "Last Chat Topic", " Target Intake Date" and a rolling engagement score updated nightly. Nothing flows back. Salesforce stays exactly as governed as it was before the integration existed, and the admissions team gets a genuinely richer record without opening up a second write path into their CRM. That's the point of offering unidirectional as a real option rather than a stripped-down version of the "full" integration. For a lot of institutions, it is the full integration they need.
What actually gets configured
None of this requires a development team on the university side. Setting up the sync means three things: authenticating EduSight against your Salesforce org, mapping the fields you care about (standard and custom, in whatever combination makes sense), and choosing direction: one-way in, one-way out, or both. From there, the sync runs on its own, and admissions teams keep working the way they already do, just with a fuller picture in front of them.
The point of all this
Nobody wants another system to log into. Admissions counselors already have one: Salesforce. They've usually invested years customizing it to match how their institution actually recruits students. EduSight isn't asking anyone to replace that. It's making sure the intelligence gathered every time a student chats with the AI assistant actually shows up where the humans making decisions are already looking.
If your team hasn't turned on field sync yet, it's worth a look at what's sitting in EduSight that never made it into your Salesforce reports. There's usually more there than people expect.
