Documentation/Admin

Admin Documentation

Run your institution on Cognicampus with repeatable workflows for users, programs, courses, policies, and subscription health.

Audience: Institution Admins (not System Admins)Last updated: February 2026Format: Step-by-step procedures

At A Glance

  • Onboard students, faculty, and admins under one institution safely.
  • Create programs and courses with clean syllabus and approval flow.
  • Configure governance settings that shape AI behavior for all students.
  • Keep enrollment, academic cycle, and subscription usage in control.

1. Access and Scope

Institution admins operate only inside their own institution boundary.

Sign in to Admin Console

Objective: Confirm you have institution-admin access before making changes.

Procedure

  1. Open app.cognicampus.com in a clean browser session (preferably a dedicated profile for admin work).
  2. Enter your institution-admin email and password on the login screen.
  3. Submit login and wait for session initialization to complete.
  4. If login does not move forward, verify credentials first, then retry after refreshing once.
  5. After successful authentication, open /admin directly if you are not redirected there automatically.
  6. Verify that the Admin sidebar is visible on the left and contains all expected menus.
  7. Confirm these menus are present: Dashboard, Programs, Courses, Users, Policies, Subscription, and Settings.
  8. Check the top header and confirm the institution name matches the institution you are supposed to manage.
  9. If institution name is incorrect, stop immediately and sign out before doing any create/update/delete action.
  10. Open Dashboard and wait for KPI cards and charts to load; this confirms role access and session health.
  11. Open Users page and confirm student/faculty/admin tabs load without authorization errors.
  12. Open Programs and Courses pages briefly to confirm read access across core admin modules.
  13. Keep this quick access check as your daily first step before operational tasks.
  14. If any admin page returns unauthorized/forbidden unexpectedly, re-login once and then escalate with screenshots and time of failure.

Understand role limitations

Objective: Avoid actions that belong to system-level administration.

Procedure

  1. Institution Admin actions are constrained by `profiles.institution_id`; all core admin screens and APIs are intended to operate within that institution.
  2. Treat every create/update/delete as institution-scoped, even when the UI shows global-looking identifiers.
  3. Do not attempt cross-institution data fixes manually; if a user/program/course belongs elsewhere, escalate to platform support.
  4. Before bulk operations, verify row ownership and mappings (program, cycle, and course) so writes stay in your institution scope.
  5. Faculty and student assignment flows assume same-institution entities; do not mix records from separate institutions.
  6. Use least-privilege admin behavior: add only required admins and avoid unnecessary account proliferation.
  7. The last institution admin cannot be deleted by API; still, operationally keep at least two valid admins for continuity.
  8. For ambiguous behavior, run a small controlled update first (single record) before any bulk action.
  9. If you see Unauthorized or Forbidden on expected routes, re-check session and active account before retrying.
  10. Escalate with route, timestamp, institution, and affected record IDs when scope-related errors persist.

2. User Management

Run onboarding and access operations from the Users page.

Add one student

Objective: Create an individual student with optional auth credentials.

Procedure

  1. Open Users -> Students tab and click Add Student.
  2. In the dialog, fill required fields: Name and Email.
  3. Use Password only if you want to create login credentials immediately; if blank, only roster entry is created.
  4. Fill Student ID when available (`student_identifier`).
  5. Select Batch/Cycle (`academic_cycle_id`) and Program (`program_id`) using dropdowns; both support `none` for legacy/no-mapping cases.
  6. Review Name, Email, Cycle, and Program carefully before submit.
  7. Submit and wait for success confirmation; do not double-submit while request is in progress.
  8. After creation, verify the student row appears in Students table.
  9. Use row action Manage Enrollments to assign initial course enrollments.
  10. If creation fails, check session validity, subscription seat availability, and duplicate/invalid data.

Import students by CSV

Objective: Bulk-create students with cycle and program mapping.

Procedure

  1. Open Users -> Students tab -> Import CSV and download the sample CSV template first.
  2. Use headers like Name, Email, Identifier, Password, Program, and Cycle (case-insensitive parsing).
  3. Each row must have valid Name and Email to be considered valid.
  4. Program and Cycle are effectively required at import time: either resolved from CSV values or selected from the dialog defaults.
  5. Upload file and review preview counts (valid vs invalid rows).
  6. Fix rows with invalid emails or missing required mappings before final import.
  7. If CSV program/cycle names do not exactly match existing entities, apply fallback defaults in the dialog selectors.
  8. Run import and wait for completion response; do not re-submit while processing is in progress.
  9. The API may return partial success; re-import only failed rows after correction.
  10. Sample-check imported student rows and then run enrollment assignment as needed.

Manage faculty and admins

Objective: Maintain teaching and administrative access safely.

Procedure

  1. Use Faculty tab to add one faculty, import faculty CSV, and assign faculty to one or more courses.
  2. After creating faculty, run Assign Courses so faculty can see those CKBs in `/faculty` dashboard.
  3. Faculty create/import calls create auth users and faculty records; if onboarding policy requires password reset, enforce it operationally.
  4. Use Admins tab to add institution admins with name, email, and password.
  5. Before deleting an admin, confirm at least one other admin remains active.
  6. The delete API blocks deleting the final admin in an institution.
  7. Review faculty and admin rosters periodically and remove stale access.

3. Programs Management

Programs are the parent layer for course setup, enrollment logic, and reporting consistency across your institution.

Create a program

Objective: Set up academic structure before creating courses.

Procedure

  1. Before creating, confirm this program does not already exist under a variant name to avoid duplicates.
  2. Open Programs page and click Create Program.
  3. Enter program name using your institution’s canonical naming standard (avoid informal abbreviations unless officially used).
  4. Set duration accurately because this value influences catalog readability and downstream reporting.
  5. Choose status intentionally: use draft for setup-in-progress and active only when ready for course onboarding.
  6. Submit creation and wait for the success confirmation.
  7. Verify the program appears in the Programs table with correct name, duration, and status.
  8. Confirm course count is initially expected (typically zero at creation).
  9. If the program is for a new intake, coordinate cycle setup and student onboarding timeline before adding courses.
  10. Create an internal owner assignment for the program so follow-up actions (courses, policies, and enrollments) are accountable.

Update or delete a program

Objective: Keep catalog clean while avoiding accidental data loss.

Procedure

  1. Use Edit action for controlled metadata updates (name, duration, status) instead of recreating the program.
  2. When renaming, verify related stakeholders can still identify the program in course and user workflows.
  3. After any edit, refresh and confirm the updated value is reflected in Programs and course filters.
  4. Treat delete as a high-risk operation because dependent courses and enrollments can be impacted.
  5. Before delete, audit dependent entities: attached courses, student enrollments, and faculty assignments.
  6. If dependencies exist, decide whether to archive/migrate first instead of hard delete.
  7. Capture a pre-delete snapshot (program id, name, related course list) for audit and recovery context.
  8. Execute delete only after approval from relevant academic owner when active cohorts could be affected.
  9. Post-delete, validate consistency in Programs table, Courses page filters, and enrollment dialogs.
  10. If a wrong program was deleted, escalate immediately with program id, deletion time, and impact summary.

Validate program integrity after changes

Objective: Ensure program-level changes do not silently break downstream workflows.

Procedure

  1. After create/edit/delete actions, open Courses page and verify program filter behavior is correct.
  2. Check Add Student and Import Student dialogs to confirm program appears (or is removed) as expected.
  3. Validate that existing students retain valid program mappings after metadata changes.
  4. Confirm no orphaned courses remain without intended program linkage.
  5. Log program change details in your admin operations record for traceability.

4. Courses and CKB Workflow

This workflow controls the full CKB lifecycle: creation, syllabus quality, content completeness, approvals, enrollments, and teaching ownership.

Create course manually

Objective: Add one course with explicit syllabus JSON.

Procedure

  1. Open Courses -> Add Course -> Manual Entry.
  2. Select target Program first; verify you are not attaching the course to a wrong program context.
  3. Enter canonical Course Name and Course Code exactly as used in institution records.
  4. Check for existing duplicate course codes before creation to avoid parallel CKB confusion.
  5. Paste syllabus JSON with strict structure (`units` array and topic lists per unit).
  6. Validate JSON syntax before submit; malformed payloads will fail or produce incomplete structures.
  7. Submit and wait for success confirmation without re-clicking submit.
  8. Verify the course appears in list with expected draft/pending state.
  9. Open course detail page immediately and inspect Syllabus Editor for unit order and topic completeness.
  10. Correct structural issues before assigning students or faculty.
  11. Mark course as ready for content QA only after syllabus integrity passes.

Create or update courses from syllabus PDF

Objective: Bulk-generate CKBs from institutional syllabus documents.

Procedure

  1. Open Courses -> Add Course -> Upload Syllabus PDF.
  2. Select target Program and upload the source syllabus PDF document.
  3. Submit and wait for processing (PDF extraction -> AI structuring -> DB write).
  4. This flow upserts by `program_id + course_code`: matching courses are updated, new codes are created.
  5. After completion, open affected courses and verify syllabus structure in Syllabus Editor.
  6. Fix structure/content issues before approving CKBs.

Review and approve CKB

Objective: Publish only after syllabus and content integrity checks.

Procedure

  1. Open a course from Courses table using View.
  2. Use Syllabus Editor tab to verify units/topics and save structure updates.
  3. Use Topic Content tab to review chunks per topic; generate missing topic content where needed.
  4. Use Progress tab to ensure topic rows exist and can be tracked.
  5. Click Approve CKB. The approval dialog checks missing topics and can auto-generate them before setting status to approved.
  6. Use Reject to set status back to draft and clear existing syllabus chunks for that course.
  7. After approve/reject, refresh Courses list and confirm status badge changed as expected.

Manage student enrollments to courses

Objective: Ensure each student is enrolled in the right CKBs.

Procedure

  1. Go to Users -> Students and select one student for individual sync or multiple students for bulk add.
  2. Use Manage Enrollments for single-student full synchronization and Enroll in Course for batch addition.
  3. Filter by Program inside the enrollment dialog to reduce accidental cross-program assignment.
  4. Select target courses carefully and save; wait for success confirmation.
  5. For single-student edits, confirm both additions and removals are reflected correctly.
  6. For bulk assignments, sample-check multiple students after completion.
  7. Validate that newly enrolled students can access course context in learning workspace.
  8. When enrollment fails, check subscription capacity, institution ownership constraints, and session validity.
  9. Re-run only failed subset after correcting root cause instead of repeating full batch blindly.
  10. Record enrollment batch details in operations log for reconciliation.

Assign faculty to courses

Objective: Map teaching responsibility to each CKB.

Procedure

  1. Go to Users -> Faculty tab and select one or multiple faculty profiles.
  2. Click Assign Courses and use search/filter to locate exact courses quickly.
  3. Select one or more CKBs and submit assignment.
  4. Verify success confirmation and refresh state to ensure backend write persisted.
  5. Ask at least one faculty member to confirm course visibility in faculty dashboard.
  6. Review assignments after timetable updates to keep ownership aligned with teaching reality.
  7. Use periodic audits to remove stale assignments and prevent confusion in faculty analytics.

Troubleshoot CKB workflow blockers

Objective: Recover quickly when course setup, approval, or assignment flows fail.

Procedure

  1. If course creation fails, validate required fields, program scope, and JSON structure first.
  2. If PDF ingestion quality is poor, retry with cleaner source files or split large documents by course.
  3. If approval is blocked by missing content, generate missing topics and re-run quality checks.
  4. If reject/approve state does not persist, refresh and verify auth session before retrying.
  5. If enrollment fails, check student license capacity and institution ownership constraints.
  6. If faculty assignment fails, ensure selected faculty and courses belong to the same institution.
  7. Use small controlled retries (single record) before repeating bulk operations.
  8. Capture route, payload context, timestamp, and error details when escalating unresolved issues.

5. Policies and Governance

Policy changes are institution-wide controls and should be treated as governed operational decisions, not ad hoc toggles.

Configure AI boundaries

Objective: Control response behavior and syllabus strictness.

Procedure

  1. Open Policies page from admin navigation.
  2. Review and set each available toggle: Strict Syllabus-Only Mode, Allow Real-World Examples, Exam-Oriented Answers, Natural Voice TTS, Require Syllabus Disclaimer, and Allow Faculty Override.
  3. When Strict mode is enabled, the examples toggle is disabled in UI.
  4. Natural Voice TTS maps provider to `natural`; disabled maps to `standard`.
  5. Click Save Changes to upsert institution policy values.
  6. Policy updates apply institution-wide and immediately affect active sessions.

Run governance checks

Objective: Use dashboard signals to catch quality drift early.

Procedure

  1. Run a fixed weekly governance review cadence (same day/time) to maintain consistency.
  2. Open Dashboard and review out-of-syllabus rate, interaction volume, session depth, and engagement trend changes.
  3. Identify courses with low engagement, stale coverage updates, or unusual quality feedback patterns.
  4. Check faculty participation indicators and highlight courses with delayed topic progression updates.
  5. Classify findings by severity: immediate action, monitored risk, or informational trend.
  6. Assign each actionable finding to a specific owner (admin/faculty) with target completion date.
  7. Apply smallest effective intervention first (policy tune, faculty correction, or course content fix) before broad changes.
  8. Track post-intervention metrics in the next review cycle to validate whether the action worked.
  9. If quality drift persists across multiple cycles, escalate to structured remediation with system-level support.
  10. Maintain a governance changelog capturing issue, root cause hypothesis, action, owner, and follow-up result.

Execute safe policy rollout

Objective: Deploy policy changes with minimal disruption and clear accountability.

Procedure

  1. Group policy updates into planned change windows instead of continuous live tweaking.
  2. Avoid combining unrelated major changes in one rollout to preserve causality in outcome analysis.
  3. If possible, start with one high-signal course cohort and observe metrics before institution-wide adjustment.
  4. Communicate expected behavior change to faculty before rollout and provide quick reference guidance.
  5. Apply policy change and verify it persists after page refresh.
  6. Monitor first 24-48 hours for abnormal engagement drops, answer quality complaints, or support noise spikes.
  7. If adverse impact appears, rollback to prior safe baseline and log rollback reason clearly.
  8. Close rollout only after post-change metrics stabilize and owners acknowledge expected behavior.

Handle governance incidents

Objective: Respond systematically to policy-related failures or quality escalations.

Procedure

  1. Treat high out-of-syllabus spikes, severe answer-quality complaints, or access-impacting policy errors as incidents.
  2. Capture incident context immediately: affected courses, time window, policy state, and user impact.
  3. Freeze non-essential policy changes during incident triage to reduce noise.
  4. Coordinate with faculty to validate whether issue is content-related, policy-related, or workflow-related.
  5. Apply targeted fix first (course content correction, policy rollback, or faculty guidance update).
  6. Validate recovery through dashboard trend stabilization and sampled user session checks.
  7. Document incident timeline, root cause, corrective action, and prevention action in governance records.
  8. Review incident in next weekly governance meeting and update operating rules if needed.

6. Settings and Academic Cycles

Academic cycles define cohort boundaries for progress tracking, enrollment behavior, and reporting integrity.

Create academic cycle

Objective: Define active teaching batch windows for your institution.

Procedure

  1. Open Settings -> Academic Cycles and click New Cycle.
  2. Enter Batch Label; optionally set Start Date and End Date.
  3. Submit Create Cycle and confirm the new row appears in cycle table.
  4. New cycles are created as active by API (`is_active: true`).
  5. Use clear, unique labels because student onboarding and topic progress filtering depend on this mapping.

Apply cycles in student onboarding

Objective: Ensure new students are mapped to a valid cycle.

Procedure

  1. During Add Student, set cycle explicitly for every new record.
  2. During CSV import, ensure cycle values map exactly to existing labels before final submit.
  3. Do not rely on memory for cycle mapping; verify selected cycle in UI for each onboarding batch.
  4. Use legacy no-cycle assignment only in controlled migration scenarios with explicit approval.
  5. After onboarding, sample-check student records for cycle correctness and completeness.
  6. Correct missing or wrong cycle assignments before running bulk course enrollments.
  7. When moving students between cycles (rare), document reason and date for audit consistency.

Audit cycle data quality

Objective: Prevent reporting and progress corruption caused by bad cycle mapping.

Procedure

  1. Run periodic audit of students with missing cycle assignments.
  2. Check for cycles with zero members that should be active and investigate onboarding gaps.
  3. Identify cycles with unexpected student spikes and verify import quality for those batches.
  4. Ensure cycle labels used in CSV sources match production labels exactly.
  5. Review topic-progress behavior on sampled students to confirm cycle-scoped data is behaving correctly.
  6. Log audit findings and corrections in your admin operations record.

Operate cycle transitions safely

Objective: Handle new intake starts and old cycle wind-down without breaking active operations.

Procedure

  1. Before a new intake starts, create the incoming cycle in advance and validate naming/date accuracy.
  2. Freeze non-essential bulk imports during transition windows to reduce mapping mistakes.
  3. Train onboarding admins on which cycle should be used for each intake batch.
  4. After transition, verify first onboarding cohort has correct cycle assignments end-to-end.
  5. Keep historical cycles discoverable for analytics; avoid destructive cleanup of past cycle context.
  6. If transition errors occur, fix cycle assignments first, then rerun downstream enrollment actions.

7. Subscription and Capacity

Subscription status and seat capacity directly control onboarding continuity and access to AI learning workflows.

Monitor license usage

Objective: Stay within student capacity and avoid enrollment failures.

Procedure

  1. Open Subscription page at least weekly and review student usage against max licensed capacity.
  2. Track remaining seats before every bulk student import, intake launch, or transfer batch.
  3. Set and enforce warning thresholds (for example 80 percent, 90 percent, and critical threshold).
  4. When threshold is crossed, notify responsible stakeholders immediately and pause non-essential onboarding.
  5. Forecast near-term seat consumption using planned onboarding numbers, not only current usage snapshot.
  6. Prioritize seat allocation for active academic cohorts if capacity is constrained.
  7. Coordinate renewal or upgrade requests with leadership/procurement before reaching hard capacity limits.
  8. After any license change, re-verify displayed limits and reconcile with expected contract values.

Track plan status and expiry

Objective: Prevent feature suspension due to trial/plan expiry.

Procedure

  1. Review plan type, status, and remaining days during every weekly admin operations review.
  2. If status is trial, set internal decision deadline well ahead of expiry.
  3. Define renewal workflow owner, approvers, and submission timeline to avoid last-minute delays.
  4. If remaining days enter risk window, escalate priority and track renewal progress daily.
  5. Treat paused or expired status as high-priority operational incident because student access may be blocked.
  6. Coordinate recovery immediately with Cognicampus support and internal approvers.
  7. After status restoration, verify user-facing operations (student onboarding, learning access, and enrollment updates) are functioning.
  8. Capture expiry-risk and recovery actions in admin logs for future planning improvement.

Run subscription readiness checks

Objective: Validate subscription health before high-volume academic operations.

Procedure

  1. Before bulk onboarding, open Subscription and verify status, time remaining, and student license usage.
  2. Confirm `current students / max students` has enough headroom for planned batch size.
  3. If seats are insufficient or status is expired, pause imports and resolve entitlement first.
  4. Re-check the page after plan updates before resuming user creation.

Handle capacity or entitlement incidents

Objective: Recover quickly when subscription limits block admin operations.

Procedure

  1. Identify incident type first: seat limit reached, trial expired, subscription paused, or missing entitlement record.
  2. Capture context: institution id, current status, attempted operation, affected user count, and timestamp.
  3. Pause repeating failed bulk operations to avoid compounding confusion.
  4. Communicate temporary impact to faculty/admin users so they can adjust immediate onboarding expectations.
  5. Work with Cognicampus support to resolve entitlement state and confirm backend status update.
  6. After fix, retry with a small validation batch before re-running full bulk operation.
  7. Complete post-incident review with root cause and preventive controls (forecasting, alerts, earlier renewal trigger).

Related Links

Go to Platform LoginInstitution SolutionsPrivacy PolicyContact Team