When admissions, advising and advancement have each built their own corner of Salesforce, a health check shows where student data is exposed and where it no longer agrees.
In education, a health check starts with a simple question: who can see what about a student, and why. We review profiles, permission sets and sharing across admissions, student success, advising, career services and advancement, then look at how applicant, student and alumni records connect. We inventory the apps, packages and automation each department added, check integrations with the student information system, and review how accounts for student workers and adjuncts are created and removed. The output ranks risks to student privacy first, followed by data quality and technical debt that affect recruitment and retention reporting.
Institutions rarely roll out Salesforce as one project. An admissions office adopts it, advising follows a few years later, and advancement arrives with its own consultant and conventions. Each group adds fields, record types and packages, and the org becomes several systems sharing a login page. Users also change with the academic calendar: student workers, graduate assistants and part-time faculty come and go every term, so stale access is a constant risk. Education records carry legal protections, and departments often have different views on what can be shared. A health check gives the institution one neutral picture that every office can act on.
We test what a sample of users in each office can see: grades, disability accommodations, financial aid notes, conduct flags and advising case notes. Sharing rules and report folders are compared against each role's actual need. We pay particular attention to shared reports built years ago and forgotten, since those are a common route by which sensitive student details reach people who should not have them.
Student workers and adjuncts are often provisioned quickly at the start of term and never removed. We list inactive and orphaned accounts, users with administrator permissions they no longer need, and shared logins used by front desk or call center staff. We also review whether identity provider sign-on is enforced and whether deprovisioning is tied to enrollment or employment status.
Each department's build is catalogued: record types, custom objects, installed packages and flows. We identify where two offices track the same thing differently, such as events or interactions, and where one office's automation changes a record another office relies on. The result is a map of shared and owned components that governance committees can use to agree on standards going forward.
A person may be a prospect, applicant, student, alumnus and donor across many years. We measure duplicate people, mismatched identifiers from the student information system and broken links between student and alumni records. Findings show how often an advancement officer or advisor is looking at an incomplete history, and which matching rules would reduce new duplicates without merging distinct people by mistake.
We start with the central IT or CRM governance group, then interview a representative from each office that uses Salesforce. Access is read-only and we avoid registration and application deadlines, when changes and even interviews are unwelcome. Findings about student privacy go to the data steward or registrar before wider circulation. The final report is organized by office as well as by risk, so each department can see its own action items while the governance group sees the institution-wide picture and shared priorities.
We confirm which system owns enrollment, program and graduation data, whether identifiers match cleanly, and whether sync errors are being logged and resolved or silently ignored.
Where course activity feeds early alerts, we review what data crosses over and whether it is limited to what advisors need rather than full gradebook detail.
We check how user accounts are created and disabled, and whether sign-on policies cover every user type, including student workers and external partners.
Education records are protected under FERPA, and each institution interprets legitimate educational interest in its own way. The review documents who can access what so your registrar and counsel can judge whether it matches your policies. It does not replace their judgment or provide legal advice.
An at-risk flag set by advising may not match the retention office version, and inquiry counts differ between recruitment teams. Before building dashboards or AI features across departments, agree on those definitions, or cross-office reports will show numbers that no single office recognizes as correct.
Advising and counseling notes can contain health, family or conduct details. AI summaries and search features should be tested against these records before launch, to confirm that an agent or copilot cannot surface a sensitive note to a user who could not open it directly.
Yes. Separate orgs are common in higher education, and we can review each on its own terms and then look at how they exchange data. Often the most useful findings sit in the gap between them, such as alumni records that no longer match, or student data copied into the advancement org without the same restrictions that apply on the student side.
We work with read-only access and look at configuration, metadata and aggregate data quality measures rather than reading individual student files. Where we need to test visibility, we use sample users and report what a role can reach, not the content itself. If your policies require it, we sign the institution's data agreements before any access is granted.
It is one of the best times to run one. A move to a new data model exposes every inconsistency in the current org, and the review tells you which records, packages and automations are worth carrying forward. Institutions that skip this step tend to rebuild old workarounds in the new structure and lose much of the benefit they expected.
The areas are similar, but the emphasis shifts. Districts and private schools usually have families as primary contacts, minors' data under additional state rules and smaller admin teams. We scale the review accordingly, with more attention to parent and guardian access through portals and to who can export student lists, and less to the multi-department sprawl typical of universities.
One onshore team with 150 Salesforce certifications, a Salesforce Consulting Partner since 2017.
A monthly brief for the people who own Salesforce, AI and revenue technology
What changed in Salesforce and AI this month, and what to do about it.
One email a month. Written by the consultants who deliver the work, not by a marketing team, for the leaders who make the technology decisions.
Consultant analysis, not vendor recaps. One click to leave.