Course Catalog and Curriculum Approval Software Problems: The 6 That Cause Graduation Appeals, and How to Avoid Them

Why does approval routing never survive contact with the bylaws?

A new course in arts and sciences goes to the department, the college curriculum committee, then the general education committee only if it carries a general education attribute, then the senate curriculum committee, then senate, then the provost. A new degree program adds the board, your state coordinating board, and a substantive change notification to your accreditor. A course number change below 500 skips three of those steps. A cross listed course needs both departments and neither wants to be the owner of record.

Curriculog and Kuali both support configurable workflows honestly. The wall institutions hit is that the routing depends on the content of a proposal rather than its type, that quorum and voting rules mirror senate bylaws which are amended on their own schedule, and that a workflow configured once against last year's bylaws stops matching how the committee actually votes. Once it stops matching, faculty go back to email, and the tool becomes a record of what happened elsewhere.

The design that survives expresses routing as rules over the proposal's own attributes. Carries a general education attribute, therefore add that committee. Increases program credits past the threshold, therefore add the state packet step. Crosses colleges, therefore require both deans. Voting is modelled properly with quorum, abstentions and recorded dissent, and a proposal can be returned to a specific step rather than to the start, which is the feature faculty ask for most and the one most tools handle worst.

What goes wrong when catalog years and legacy curriculum data migrate?

Curriculum migrations fail on a single conceptual error: treating the catalog year as a label on a record rather than as a version of it. The legacy data usually arrives that way, because the incumbent system let people edit in place and nobody kept the prior state.

The practical consequences appear immediately. There is no reliable answer to what a program required in a given year, so the migration has to reconstruct history from published catalog PDFs, which is genuine archaeology and takes weeks. Requirements that were corrected mid year exist only in their corrected form, so students who enrolled under the original wording have no record supporting the plan their advisor built. Courses that were retired and reused under the same number in a later year collapse into one record and silently merge two different courses.

The only workable approach is to import each published catalog year as its own immutable version with effective terms, accepting that older years will be less complete than recent ones and recording that gap honestly rather than smoothing it. Then reconcile a sample of active students against their own catalog year and see whether the requirements the audit enforces match the version they enrolled under. Every institution that runs this check finds cases. Finding them during migration is far cheaper than finding them in an appeal.

Why do student information system and degree audit integrations break after launch?

Because the two write paths are different problems and most projects budget for one. Writing a course master record in Banner, Colleague, PeopleSoft Campus Solutions or Workday Student is bounded work with a governance conversation attached that is usually longer than the engineering. Generating a degree audit rule is not bounded in the same way, because scribe syntax is unforgiving, a rule expresses intent rather than data, and the same senate motion can be scribed several defensible ways.

What breaks after launch is the silent write. A change is pushed, something is rejected or partially applied, and nobody reads the log because the proposal shows as approved. The catalog is right, the system is wrong, and the divergence is discovered by a student.

Design the write as a reviewed diff rather than a sync. The system proposes the exact course master change, the exact prerequisite expression and the exact audit rule, a human approves the diff, it writes, and it reads back to confirm what actually landed. Anything that fails goes to a visible queue with an owner. The single highest value upstream fix is a structured prerequisite editor in the proposal form, so faculty pick courses, operators, concurrency and minimum grade conditions instead of typing a sentence that somebody else must translate. That one change removes the largest source of translation error in the whole category.

What happens when impact analysis and state reporting are not covered?

A department wants to retire a course. It is a prerequisite for four courses in two other colleges, a required course in three programs, an approved elective in eleven, part of a general education category, named in two articulation agreements with community colleges, and referenced in a state approved program description. The person retiring it knows about one of those.

Text search in a catalog tool finds mentions in prose. It does not find the audit rule that references the course inside a scribe block, and it certainly does not find an articulation agreement sitting as a PDF on the transfer office's drive. So the retirement passes, and the damage surfaces in registration when students cannot enrol in something they need.

Model the curriculum as a graph and make impact analysis a required step before a proposal can advance, with automatic notification to every owning department and a comment window. This turns a category of political ambush into a procedural step, and provosts value it more than any other single feature because it stops curriculum fights from reaching their office. State coordinating board packets are the other common omission: they have their own formats and their own deadlines, and building them late means assembling them by hand for at least one cycle.

Should you build custom or configure what you already own?

If you are under roughly 2,500 students with a stable curriculum, one or two approval bodies and straightforward rules, buy. Acalog with Curriculog or Coursedog will serve you, and building would be an expensive way to get a worse catalog website. CourseLeaf is a serious product and if your governance genuinely fits its model, use it and put the money into documenting your bylaws instead.

Here is the uncomfortable part of the buy case. The catalog website is the least valuable thing in this category and it is what vendors demonstrate. Before you scope anything, run a small audit: take twenty program requirements, compare the published catalog against what the degree audit actually enforces, and count the differences. If the answer is zero, your process works and you need a publishing tool. If the answer is four, no publishing tool will fix it, because the problem is downstream of publication.

Build when your routing depends on proposal content rather than type, when you have documented drift and are handling appeals because of it, when you need generated audit rules rather than a second person interpreting the same motion, when a system office adds its own approval layer, or when faculty have routed around the official form to the point that changes enter the student information system without passing through governance. That last one is a compliance problem wearing a usability costume.

How do hidden costs get into the quote?

In our delivery experience a focused first release with a conditional proposal form, rule based routing that matches your bylaws with real voting, immutable catalog year versioning and a validated write into the course master runs $65,000 to $140,000 and ships in 12 to 16 weeks. A full platform adding degree audit rule generation, structured prerequisites, impact analysis across the curriculum graph, state program packets, articulation tracking and public catalog publishing runs $160,000 to $350,000 phased over 6 to 12 months.

Three things reliably push a quote past its band. Approval bodies, because five bodies with content dependent routing is far more than five times one body, and the discovery work of writing down what your bylaws actually say is usually the longest part of the project. Write access to the student information system, where the integration governance conversation with your database administrators and security team is calendar time nobody controls and it sits on the critical path.

And degree audit generation, because scribe syntax takes real iteration and the first three rules teach you what the next hundred need. Ask for these as separate line items. Also ask what happens to proposals that are in flight at go live: institutions that plan to launch mid cycle and finish existing proposals in the old process do fine, and institutions that try to migrate live proposals lose weeks.

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

Ask them to explain how a course change becomes a degree audit rule. A developer who has done this will talk about prerequisite expression trees, scribe block generation, effective terms and a human approved diff. A developer who says they will sync it through an interface has not looked at what an audit rule actually is and will discover it three months in, at your expense.

Ask how they will handle a mid year correction to a published catalog. If the answer involves editing the record, they do not understand that the catalog is a contract with students, and you will permanently lose the ability to answer what it said on the day someone enrolled. The correct answer is a new version with a documented reason and the prior version still queryable.

Ask what write access they need and how they intend to get it approved. The right answer starts with your database administrators and integration governance team and includes staged validation, not a claim of experience with your platform. A developer who has done this raises the politics before you do.

Ask how the proposal form behaves for a title correction. If it shows ninety fields, faculty will route around it and your governance problem returns wearing a new interface. Then settle ownership of the code and the curriculum data in writing before kickoff. At Digital Heroes the client owns the code from the first commit. Curriculum history is legally significant to every student who has ever enrolled and should never sit in an account you cannot reach.