Admin Manual

Manual scope

This manual covers the Admin app’s product features and role permissions. System configuration, authorization configuration, deployment and security operations are internal and are not described in public documentation.

Role and permissions

What you can do in the Admin app is decided by the server from your roles, not by hiding buttons. Four roles matter here:

• Admin (platform admin): can use every platform feature, including the Teacher app’s content. Creating and changing sessions, exporting data, granting and revoking roles, suspending accounts and certificate management are all possible.
• Credential Admin: runs certificate management, for example activating rubrics and credential definitions, proposing issuance-policy changes, manually issuing and revoking certificates, and practical assessment review. A Credential Admin cannot grant roles, manage sessions or export data.
• Course manager: for a single course, consents to or declines changes to that course’s certificate issuance policy, and can assign instructors to that course’s sessions.
• Instructor and teaching assistant: for a single session, use the Teacher app to see that session’s aggregate results and teaching materials.

One person can hold several roles. A role applies only within its scope; for example, a course manager role only covers the courses it was granted for.

• Roles and permissions

Sign-in and access

The Admin app requires signing in, the same way as any other account (Google, or email and password). Sessions, people, analytics and data exports need the admin role; certificate management and review screens follow the server-side permission check, and you see an unauthorized message if you lack it. Admin pages show the site top navigation and footer, plus a sidebar of their own.

• Go to the Admin app (sign-in required)
• Access and roles

Admin app overview

The Admin app home summarizes three things that need attention: sessions that are currently open, items waiting in the certificate review queue (including issuance-policy changes that went unanswered past their deadline), and recent access changes. The sidebar then offers these pages:

• Admin app home: the three summaries above and links to every page
• Sessions: create sessions, change their status, and open a single session’s detail page
• People and Access: the user directory, plus granting and revoking roles
• Certification Administration: readiness, rubrics, credential definitions, issuance policy, issued certificates, manual issuance and recent activity
• Projects: campus co-creation projects and industry endorsements
• Analytics: learning, application and product analytics
• Data Exports: download CSVs by course and data type
• Reviews: industry case library and IL course work reviews, each course’s Use Case review queue, rubric results, certificate eligibility rules and the certificate review queue, and practical assessment review

• Admin app home (sign-in required)

Sessions

A session is one actual run of a course. You enter a session code, name, date and status when creating it; the code is suggested from the name and date and you can edit it, but it must be unique across the platform. Changing a status asks for confirmation first. Select a session code or name in the list to open that session’s detail page, where you see its basic data and can change its status; the detail page keeps no status history and has no per-session export.

• Create and manage sessions
• Sessions (sign-in required)

Session scope

A session can be "bound to one course" (recommended) or "not bound" (an event code that works for any course). Binding decides which course managers can manage the session, so a change shows its impact first and is written to the audit log.

• Create and manage sessions

Session lifecycle

1. 1Draft
   The default; not yet open to learners
2. 2Open
   Learners can take assessments, submit forms and sync progress
3. 3Closed
   No more submissions; data stays viewable
4. 4Archived
   Kept as a record after the course

Learner aggregate status

Learners are identified by learner code; real names are not stored. You can see a session’s aggregate results and the lesson completions of learners who joined progress sync.

Assessments

Assessments are scored on the server, and correct answers are kept only on the server, never on any public page. The Admin and Teacher apps show aggregate results, and quiz results can be exported. For practical work that needs a human score, a Credential Admin or an assigned assessor scores it against the rubric in the practical assessment review under Reviews; the final result is always computed on the server.

Use Cases and Canvases

Learner Use Cases, Canvases and Exit Tickets stay private to the learner and the assigned instructor/admin; they are only available through CSV exports and are never published to a public gallery.

A separate public Industry Case Library exists for organization-sponsored industry projects. A case only appears there after the underlying project completes its gate lifecycle and its content is approved by the sponsoring organization, privacy review and academic review: a different, three-party process, not a single admin decision on a learner's own Use Case.

• Public case library

People and access

The People and Access page has two parts. The top is the user directory: every registered user, searchable by name or email and filterable by account status, where you can suspend, disable or reactivate an account (each change asks for confirmation). The bottom manages roles: it lists current admins, Credential Admins, course managers and session instructors or teaching assistants, and lets you revoke them (after a confirmation; the platform’s last admin cannot be revoked). Every role change is written to the audit log.

Granting a role uses a three-step wizard: pick the person, choose the role and scope, then review the summary and submit in the confirmation dialog. Once a course has a registered course manager, an issuance-policy change must go through a policy change request (the console enforces this); only a course with nobody to consent can be set directly. The Credential Admin table shows a reminder while fewer than two people hold that role, because the person who proposes an issuance-policy change cannot approve it.

• Admin: no scope.
• Credential Admin: no scope; the person must already have signed in and cannot be invited by email. Keep at least two people so one person does not both propose and approve a change.
• Course manager: choose the course from the course list; the course code is stored in the platform’s canonical spelling.
• Instructor or teaching assistant: choose the session; the role applies to that session only.

For someone who has never signed in, use the separately labeled "invite by email" option instead; the role takes effect when they first sign in with that verified email, and pending grants are listed in a table labeled "Waiting for first sign-in". Enter only the email of the person’s Google account and no other personal data.

• People and Access (sign-in required)
• Access and roles

Reviews

The Reviews page is the entry point to the review work: industry case review (sponsor, privacy and academic approval, where the academic review and publishing are done by an admin), reviews of IL 101 charters, IL 201 PoV, IL 202 readiness, IL 301 pilot logs and IL 302 roadmaps (by an instructor or admin), and practical assessment review. Further down are each course’s Use Case review queue and rubric results, certificate eligibility rules (prerequisite settings for L3 certificates) and the certificate review queue.

The certificate review queue lists learner and certificate pairs that have some or all qualifying evidence but have not been auto-issued yet, showing which requirements are met, missing or in conflict. Issuance-policy changes that went more than 14 days without a course manager response are listed separately as needing admin follow-up. Every decision is made on the server.

• Reviews (sign-in required)

Projects

The Projects page manages campus co-creation projects (create a project, manage members and assessor-verified status, advance the stage) and industry endorsements (an endorsement can only be approved by a Credential Admin, and withdrawn by the endorser or an admin; an endorsement never issues or revokes a certificate). Each project has its own detail page with members and stage history. The project list is available to Credential Admins; a project’s faculty lead can manage their own project directly by project ID.

• Projects (sign-in required)

Analytics

Analytics has three categories: learning analytics (sessions and participants, pre- and post-tests, the funnel from enrollment to completion), application analytics (Use Case and Exit Ticket counts and status distribution) and product analytics (anonymous UI events and Help Center feedback). Everything is aggregate numbers, never individual learner data.

• View analytics
• Analytics (sign-in required)

Course feedback

Under Analytics, "Course feedback" brings together feedback results, comment moderation, and form performance and retention in three tabs, with a link to the organization reports. HR contacts can be given the read-only "HR viewer" role to see only their own organization's de-identified statistics and comments.

• Manage course feedback
• Course feedback (sign-in required)

Exports

On the Data Exports page an admin picks a course, then a data type (quiz results, Use Cases, Exit Tickets, Canvases, decision records and so on, depending on the course), and downloads the matching CSV. Only courses that offer a CSV export are listed, and exports are written to the audit log.

• Export data
• Data Exports (sign-in required)

Certificates and verification

Course Completion Certificates and Capability Certificates are issued by the platform's certification system: credential definitions, evidence-based eligibility, the Skills Passport, PDF/QR certificates, Open Badges/CLR export and revocation are all managed by staff with the Credential Admin role (or admins), using the Certification Administration screen in the Admin app or the same protected APIs it calls. Which courses offer which credentials, and their exact requirements, varies by course, and a credential definition must be reviewed and activated before it takes effect; a learner must actually meet the real requirements behind it, never automatically just because a form was submitted.

Anyone with a specific certificate's verification link or code can confirm it is valid on the public verification page, which shows that certificate holder's name (a fixed snapshot taken at issuance, unaffected by a later account name change), the certificate name and version, level, issue date and expiry date (if any), related competencies and criteria, and the current status (active, expired, revoked or superseded). Completion certificates of GoAI-track courses also show the learning hours (derived from the course duration, for example 6 or 8 hours), which are printed on the PDF as well. The page never shows an email, student id or any score, and there is no way to search or list other certificates by name. The name comes from the learner’s own self-service certificate name (the display name if none is set) and is never changed by later edits; to correct an already-issued certificate, a Credential Admin handles it.

• How certification works
• Look up a certificate by code

Getting a credential ready to issue

A credential can be issued automatically only when five independent conditions hold together. The readiness checklist on the Certification Administration page shows them for every credential and tells you the next action.

• The assessment rubric is active (capability credentials only; completion credentials use no rubric)
• The credential definition is active
• The course has a registered course manager who can consent to issuance-policy changes
• The issuance policy matches the target: automatic for course completion (L1), automatic once verified for capability credentials (L2)
• No change request is waiting for a decision

The next action is decided in a fixed order: first the credential definition and rubric must exist, then the rubric is activated, then the credential definition, then the course needs a manager, and only then can an issuance-policy change be proposed; once proposed, it waits for a decision. A credential definition or rubric that does not exist yet is marked "Needs import"; a platform operator has to import it, and it cannot be created in the Admin app.

1. 1Grant the Credential Admin role
   On the People and Access page (the person must have signed in at least once)
2. 2Activate the rubric
   On the Certification Administration page, review the rubric in the Rubrics section; before activation the system checks that domain weights add up to exactly 100, that every domain has criteria, and recommends at least one critical-fail rule. Activation cannot be undone and the content can no longer be edited
3. 3Activate the credential definition
   On the same page; once active, its title and criteria are locked and only a new version can replace it
4. 4Register a course manager
   On the People and Access page, assign a course manager for the course, or let an eligible teacher claim the course in the Teacher app
5. 5Propose the issuance-policy change
   On the Certification Administration page; the course manager is notified and approves or rejects it on the Teacher policy changes page, or through the single-use link in the notification email
6. 6Wait for a decision
   A request is valid for 14 days by default; if nobody answers by then it becomes "needs admin follow-up" and an admin or another Credential Admin decides

• People and roles (Admin app)
• Certification Administration (Admin app)
• Policy changes (Teacher app)

A tour of the Certification Administration page

The page has in-page navigation at the top with the seven sections below, in this order; select one to jump to it.

• Readiness: one row per course credential, showing the five checks, the current and target issuance policy, and the next step. The summary tiles above (Ready, Needs import, Needs activation, Needs course manager, Ready to propose, Awaiting consent) filter the table when selected, and a second click clears the filter; you can also search by credential code, course code or title, or show only credentials that need action. When the next step can be done in place, the row has a matching button (activate the definition, propose the recommended policy, open the rubric, view the request).
• Bulk proposal: tick several "ready to propose" credentials in the readiness table and submit each one’s recommended policy change in one go. The dialog first lists each credential’s course, the change and how many course managers will be asked, and warns about courses with no course manager. One request is still created per credential and each still waits for course manager consent; the results show success or failure per item.
• Credential definitions: code, version, level and status for each credential, searchable by code, hiding superseded drafts by default; a draft can be activated here (with confirmation, irreversible).
• Rubrics: preview domains, weights, criteria and critical-fail rules, check the pre-activation conditions and activate.
• Issuance policy: the six policies in plain language (automatic, automatic once verified, manual review required, batch approval, council approval, issuance disabled), each credential’s current and recommended policy, proposing a change, and the request history (status, who proposed, who decided and the expiry, with approve and reject here).
• Issued credentials: filter by status, learner ID or credential definition, view one certificate’s detail and verification code, and revoke it (with confirmation, irreversible).
• Manual issuance: enter a learner ID and pick an active credential to issue; the server re-verifies eligibility and never trusts the screen. L4 credentials also need project details.
• Recent activity: a timeline built from the audit log of rubric and definition activations, issuance-policy changes, requests and decisions, and Credential Admin and course manager role changes, newest first.

Activating rubrics and credential definitions and every issuance-policy write are recorded in the audit log. The target convention is automatic issuance for completion credentials and automatic once verified for capability credentials; the other policies are for cases that need human or council review.

• Certification Administration (Admin app)
• How certification works

Privacy and data handling

• The platform identifies learners by learner code and account data, and Admin screens and exports provide only the minimum needed for the management task
• Exports, role changes and important certificate operations are written to the audit log
• Assessment feedback is shared with the learner, so never put confidential information or other people’s personal data in it
• Before manually issuing or revoking a certificate, or suspending an account, check the target and the reason

• Privacy

Troubleshooting

• Admin troubleshooting

Glossary

• Glossary