Student Conduct and Title IX Software Problems: The 7 That Undo an Outcome, and How to Avoid Them

Why does the access model get treated as a permissions setting?

This is the single most consequential scoping error in the category, and it happens because access control looks like an administrative detail on a requirements list. It is not a setting. It is the product.

In a formal grievance process there are at least six categories of person who must see different things: the complainant, the respondent, each party's advisor of choice, the investigator, the decision maker, and an appeal officer who must not have been involved earlier. Add witnesses who see only their own statement, a coordinator who oversees but does not decide, and campus partners who need to know a supportive measure exists without knowing why. The requirement is not folder permissions. It is that the same investigative report is visible in full to the investigator, in an appropriate form to each party, time bound to the review period, invisible to the appeal officer until the appeal opens, and logged every time anyone opens it.

A developer who reaches for user groups and shared folders will build something that leaks, and the leak will be discovered by a party rather than by you. The fix is to make the access rule set the first design artefact, before intake screens, before letter templates, before anything visual. Access is computed from role, party relationship, case phase and document classification together, downloads are watermarked, and the access log itself is producible as evidence. Get that right in phase one and adding the formal grievance process later is configuration. Get it wrong and phase two is a rebuild.

What goes wrong when you migrate legacy cases and records?

Conduct offices arrive at these projects with a shared drive, an email archive, a spreadsheet of deadlines and letter templates in a word processor, plus whatever their previous system holds. Everyone assumes migration means moving the previous system's records across. The harder question is what to do with everything that was never in a system.

Two specific problems recur. The first is that historical cases were decided under procedures that have since changed, sometimes more than once through federal rulemaking. Loading those cases into a model built for your current procedure quietly relabels them, so a case is displayed under phases and timelines that did not exist when it was decided. If that record is later produced, it misrepresents what happened. The second is that older records were kept without a retention decision, and importing them wholesale means you have now formally retained material you might have been entitled to dispose of. Material you retain is material that can be requested.

The fix is to decide scope with your general counsel and records officer before any migration work is quoted. In practice most offices need active and recently closed cases in the new system, an indexed archive for the rest, and a rule that historical cases carry the procedure version that governed them or are marked explicitly as pre system records. That decision takes a meeting and saves a quarter.

Why do the student information system and housing links break after launch?

Three integrations matter and each fails in a different way. The student information system, whether Banner, PeopleSoft, Workday or Colleague, supplies enrolment, directory data and registration holds. It is routine work and it is never quick, and the part that degrades is the hold: placing one is a write into a system with its own governance, and the registrar's office may change the hold codes or the approval path without telling you. When that happens, holds stop applying and nobody notices until a student registers who should not have.

Housing is the integration that makes no contact orders real. A supportive measure agreed in a meeting and never implemented is one of the most common failures in this area, and it happens because the residence life system is a separate application with a separate owner and often a separate vendor. Athletics eligibility, identity card access and international student status sit in the same category.

The third is single sign on and the security review your information security office will run. That is not an integration that breaks, it is one that arrives late and adds weeks at the end if you scheduled it at the end. Book it at the start.

The fix across all three is ownership and monitoring. Name a person in the registrar's office and a person in residence life who own the interface, alert when an expected write fails rather than logging it silently, and re test the hold path each time either system takes an upgrade.

What happens when retention, accessibility and equity reporting are not covered?

These three are deferred in almost every first release and they are the ones that create institutional exposure rather than inconvenience.

Retention is the clearest. Conduct records, formal grievance records and records relevant to Clery obligations carry different requirements, and FERPA governs what may be disclosed and to whom. Institutions default to keeping everything forever because it feels safe. It is not, and the safer position is retention by record type, a legal hold when litigation or a complaint is anticipated, and disposal on schedule with an auditable record that it happened. Your general counsel and records officer set the schedule. The software's job is to execute it.

Accessibility is not optional at an institution and it is far cheaper to build in than to remediate. A system that parties and advisors use directly will be used by people with disabilities, and a remediation project after launch costs more than doing it correctly and delays a release you have already announced.

Equity reporting is the one offices least expect to need until they are asked. The defence against an allegation that outcomes correlate with a protected characteristic is data showing outcomes were consistent with precedent and applied criteria, broken down by violation type and demographic category. If aggravating and mitigating factors were never captured as structured fields, that report cannot be produced without a manual audit of every file. Capture the factors from day one even if the reporting comes later.

Should you build custom or configure what you already own?

Many institutions should not build. If you are a single campus with one student handbook, conventional procedures and a conduct office of under about six staff, Maxient is the right answer and it is widely used for good reason. Symplicity Advocate is a credible alternative. Either will be live far sooner than a build and cost a fraction of it, and your effort belongs in training hearing officers rather than in a software project.

Before commissioning anything, exhaust the configuration you already own. Most offices running a packaged product have not fully used its letter templating, its deadline tracking or its reporting, because the person who implemented it left and nobody has revisited the configuration since. A configuration review is a week of work and occasionally removes the reason for the project.

Build when two or more of these are true. You are a multi campus system where procedures differ by campus and leadership wants one view of risk. Your professional schools run separate honour codes that sit outside the conduct system entirely. Supportive measures fail at implementation because housing, the registrar and athletics are reached by email. You cannot produce outcome consistency data if asked. Or your procedures have been rewritten twice by federal rulemaking and each rewrite cost you weeks of manual template work, which is the pattern that brings most institutions to this decision.

How do hidden costs get into the quote?

Multi campus scope is the first and largest. Each campus usually has its own handbook, its own governance and its own conduct office culture, so a second campus is a second set of procedures rather than a second tenant. Price it per campus.

The second is employee respondent cases. The moment a respondent is staff or faculty, human resources (HR) processes enter scope and sometimes a collective bargaining agreement with its own notice and representation requirements. Institutions frequently mention this in week six, having scoped a student only system.

The third is the security review and accessibility conformance, both of which are real work and both of which are frequently listed as assumptions rather than deliverables. Read the assumptions section of any proposal carefully, because that is where they hide. The fourth is procedure versioning itself. Building configuration that can be edited is straightforward. Building versioned procedures where a case opened in September remains governed by September's rules after you publish a new version in August is more work and it is the feature that determines whether the system survives the next regulatory change. If a quote does not mention versioning, it is not in there.

What separates a build that works from one that fails here?

Give a prospective developer one test before anything else: the same investigative report must be visible in full to the investigator, in a form appropriate to each party and their advisor, and not at all to the appeal officer until the appeal phase opens. If they reach for folder permissions or user groups, end the conversation. The right answer combines role, party relationship, case phase and document classification, with every access logged.

Ask how procedures are versioned. Developers who have not worked in regulated process will propose editing configuration in place, which silently rewrites the rules that live cases are running under, and that is precisely what an appeal or a court will examine. Ask what they have integrated by name, since Banner and Workday are different problems and a housing integration for no contact orders is different again. Ask when the information security review is scheduled, and be suspicious of any plan that has it in the final fortnight.

Judge the outcome on behaviour rather than features. Notice periods should be computed and enforced rather than tracked in a spreadsheet, with extensions requiring a documented reason that appears on the case timeline. Duplicate reports about the same incident should be flagged at intake rather than discovered in month three. Conflict checks against advising relationships, course enrolment and prior case involvement should run automatically, because that check is trivial for software and unreliable for people. And settle ownership in writing before kickoff. The institution should hold the repository, the cloud accounts and the right to hire another firm. At Digital Heroes the client owns everything from the first commit, which matters more here than almost anywhere, because these records and their access logs may be produced in litigation or a federal complaint.