Request a branded demo

Modules

Catalog Pathways Curriculum Board Essentials Free Assist Coming soon

Catalog

Digital catalog Program pages Courses Search Publishing workflow

Pathways

Career exploration Wage data Program outcomes Student discovery Transfer articulation

Curriculum

Proposals Approvals Vote records Evidence archive Catalog year lifecycle
Capabilities MCP Coming soon API and exports Integrations College branding
Platform overview How the modules share one record, and why that matters at publish time.
Packages Compare Catalog Pathways Curriculum Academics
Academic Affairs Catalog governance Curriculum approvals Accreditation evidence
Catalog & Curriculum Teams Publishing workflow Course and program updates Version control
Enrollment & Marketing Program discovery Career outcomes Search and conversion
Information Technology WordPress ownership Data exports SIS compatibility AI and API readiness
Need help choosing? Tell us what is hardest to manage today and we will recommend a package and setup path. See it in your own colors Request a demo We stand up a full Kenii site carrying your logo and colors, loaded with demo catalog content, so your team can click through the real thing instead of watching a slide deck.

Proof

Why colleges choose Kenii Compare with incumbents Customer stories
Documentation

3.15.1

Curriculum proposals now submit, approve and create records correctly on sites that read from the data tables, and credential requirement edits reach the tables during the save instead of at the end of the request.

  • Fixed **Submitting, voting on, approving and materializing a curriculum proposal gave wrong results once proposals read from the data tables.** While a change was being saved, the proposal was read back from the tables before they had caught up, so a submitted proposal reported itself as a draft, an approval did not advance the step, and an approved proposal created a course with no fields. Reads made during a save now come from WordPress, which is always current. The proposal check that decides whether tables may be read now also catches this, and a new check walks a proposal from creation to materialization.
  • Fixed **Credential requirement edits reached the data tables only at the end of the request.** On sites reading credentials from the tables, saving a credential rebuilt its requirements from the very table it was about to update, so the table caught up only in the end-of-request repair. It now rebuilds from WordPress during the save.