FROM FIRST VISIT TO LASTING PROGRESS
The complete ZubLMS workflow
One learning platform. Many connected journeys. Follow the people, decisions and safeguards that turn content into measurable learning.
This is a guided explanation, not live activity. It creates no accounts, requests, AI calls or messages. Setup requirements and unfinished work remain visible.
Who acts: Visitors and learners
Discover & enter
Explore the public site
Browse platform, solutions, sample courses, plans and documentation. Public samples and the explicit demo are separate from company learning records.
Decision / safeguardPublic pages do not reveal company data.
Playback starts only when you choose Play. Pause or use the step controls at any time.
Read this feature’s guideTHE COMPLETE REFERENCE
Every journey, step by step.
Expand any workflow for the complete readable sequence. These steps remain available without playback or JavaScript.
Discover & enterVisitors and learners
Explore the public site
Browse platform, solutions, sample courses, plans and documentation. Public samples and the explicit demo are separate from company learning records.
Public pages do not reveal company data.
Start sign-in
Use Sign in or your approved company sign-in link. Keycloak handles identity and returns you to the LMS.
A successful identity-provider login alone does not grant membership.
Resolve your workspace
The server checks active company membership and scoped roles. Switch only between memberships offered to your account.
An unknown, suspended or mismatched identity is denied.
Choose your role view
Use Learning space, Manage team, Author studio or Administration as permitted. Open the profile menu for account settings and sign-out.
Changing the visible view never grants a new permission.
Find your next action
Open assigned learning, deadlines, resources or messages. Your workspace reflects authorised records, not the public demonstration.
Check the current company and filters if something is missing.
Prepare a companyOwners, administrators and operators
Confirm operator access
Platform operators use Platform console to inspect clients and control slug/domain self-service. This requires an explicit operator allowlist and active owner membership.
Ordinary company administrators cannot enumerate other clients.
Set company identity
Update approved name, support details, timezone and supported branding fields in Company settings.
Recent sign-in and revision checks protect sensitive changes.
Manage current members
Owners review existing people and access. Managers see only their permitted team scope.
New-member invitation UI and editable team hierarchy remain separate work.
Prepare workspace addresses
When allowed, choose a unique slug or add a custom-domain claim and prove ownership with the displayed DNS TXT challenge.
DNS verification is not HTTPS hosting activation.
Pilot before rollout
Test permitted and denied roles, representative content, email, reports and recovery with the operator.
A local demo is not an installation-specific production acceptance.
Connect company SSOCompany owners and platform operators
Draft a connection
Create a named SAML or OIDC connection. A company can configure multiple independent providers; use the exact callback shown for each.
Do not reuse another connection’s callback or select a tenant from an untrusted email hint.
Validate the configuration
Check required fields, public HTTPS endpoints and certificates. Store secrets through the protected settings path.
Validation does not prove the remote credentials or a successful sign-in.
Request operator activation
Submit the exact reviewed revision. The operator checks identity-provider ownership and destinations before activation.
The application API does not receive identity-provider administrator credentials.
Test the intended provider
Use the explicit provider link or company chooser with an approved, linked account and membership.
A password login does not count as verified company SSO.
Maintain and recover
Coordinate credential rotation and replacement connections. Keep a tested recovery sign-in path.
Disabling a provider blocks new broker logins; existing LMS sessions require separate revocation.
Build & publish learningAuthors and administrators
Create a draft
Start a course, choose its topic and cover, then define modules and learning goals.
Existing published versions remain separate from draft edits.
Compose the sections
Add supported text, quiz, video or reviewed SCORM activities. Collapse module/section panels and reorder course sections.
Section ordering belongs to the course, not custom sidebar ordering.
Refine the content
Use the visual editor or HTML source mode. Review sanitised content, quiz answers and permitted media.
Arbitrary scripts and unrestricted HTML are not accepted.
Save and preview
Complete drafts autosave after a pause. Use draft preview to review the experience before release.
Conflicting revisions require reload and reconciliation; preview creates no learner credit.
Publish a version
Explicitly publish the reviewed draft. Assignments use immutable course versions.
A later draft edit does not silently change the content of an existing assignment.
Assign, learn & completeManagers and learners
Assign within scope
Managers select a published course, permitted recipients and a deadline.
The server rechecks both course availability and recipient authority.
Open assigned learning
The learner opens the course through My learning and resumes the assigned version.
A catalogue preview or saved bookmark is not enrolment or completion.
Work through activities
Read lessons, answer knowledge checks, watch supported videos or open a SCORM activity.
A play event or page visit alone is not proof of mastery or completion.
Persist progress
The server validates progress and assessment submissions. SCORM has its own acknowledged runtime saves.
Network failure must be surfaced; only acknowledged progress can be relied on.
Review achievement
Completed learning can produce evidence and a queued certificate render. Learners check achievements and managers review outcomes.
Rendering may be pending; a completion does not guarantee an immediately downloadable certificate.
Import & deliver SCORMAuthors and learners
Import a ZIP
Upload a permitted self-contained single-SCO SCORM 1.2 package.
Corrupt archives, unsafe paths, external launch URLs and malware are rejected.
Validate and scan
Archive checks, manifest validation and the configured malware scanner must pass.
Unavailable scanning blocks import; it is not bypassed.
Preview and approve
Test the exact export, including resume, completion, keyboard use and phones. Explicitly approve the immutable package version.
Preview does not enrol a learner or record credit.
Attach and publish
Select the approved version in a course activity, save and publish the course, then assign it.
Replacing a package does not rewrite existing assigned versions.
Launch and save
The learner runs content on an isolated host. Runtime state is saved and Finish with passed/completed is acknowledged before activity completion.
SCORM 2004, portable native-course export and hosted distribution are not delivered by this flow.
Use knowledge & AIAuthors; resources also available to members
Prepare permitted text
Create or choose current company resource-library entries. Resource reads remain company-scoped.
The AI pilot reads plain-text resources; it does not ingest PDF/DOCX files or browse websites.
Choose a bounded request
Select up to three resources, within 32,000 combined text bytes, and enter a question or course brief.
Only explicitly selected resources are attached; whole-library search is not implemented.
Confirm external processing
Confirm authority to send the selected text to the company-configured AI provider. Go rechecks author permission, versions and the company quota.
No consent, stale sources or exhausted limits stop the request.
Inspect the result
Answers include source quotations or abstain. Course proposals contain modules, lessons and quizzes for review.
Quotation matching proves text provenance, not that the interpretation is correct.
Review before use
For courses, acknowledge review and recheck sources before opening an editable draft. Publish separately.
No model-selected tools, automatic enrolment, automatic messages or autonomous publication run.
Understand & export resultsManagers and administrators
Read scoped insights
View completion, assignment status, deadlines, course bars and team/topic heatmaps.
Dashboard filters narrow the returned workspace; bounded snapshots are not unlimited historical analytics.
Request an export
Select the supported report and permitted scope in Reports. The server records a request for background work.
Submitting a request is not the same as a completed file.
Process the job
Workers produce the authorised export and track job state. Recoverable failures follow the job’s retry rules.
Scope, cancellation and current authority remain relevant while work runs.
Check history
Inspect queued, processing, ready, failed or cancelled state and the report’s availability window.
Do not repeatedly create exports when an existing job is still running.
Download with current access
Download through the authenticated report centre. Current permissions and expiry are checked again.
Revoked access cannot be bypassed with an old report link; bytes already downloaded cannot be recalled.
Send & follow deliveryAdministrators, scoped managers and recipients
Compose an announcement
Create a plain-text draft and select permitted recipients. Review subject, body and audience.
Recipients do not see the full audience list; admins cannot browse arbitrary private messages.
Choose permitted channels
In-app delivery is included. Optional email needs configured SMTP, a resolvable address and recipient opt-in.
There is no SMS, WhatsApp, push or team-chat delivery promise.
Send the reviewed revision
The server commits in-app records and any email delivery jobs transactionally.
A changed draft must be reviewed again; duplicate sends use the message’s idempotency rules.
Recheck before email dispatch
The worker checks current access, scope and preferences before handing the alert to SMTP.
Email contains a generic alert and sign-in link, not the private message body.
Interpret delivery honestly
Inspect queued, accepted, skipped, failed or uncertain status. Recipients explicitly mark messages as read.
SMTP acceptance is not inbox arrival. An uncertain hand-off must not be blindly replayed.
Track activity responsiblyAdministrators, learners and operators
Configure destinations
Operators configure provider credentials; administrators select available events and enable each destination.
Adapters being present does not mean a destination is active.
Choose privacy preferences
Analytics and marketing permissions are independent and default to off.
Core learning records are separate from optional analytics or advertising sharing.
Collect supported events
The app records supported page, course and video activity. Provider players use supported APIs where configured.
A generic third-party iframe does not automatically expose detailed playback events.
Deliver with controls
The server applies consent, configuration and event rules before optional delivery to configured services.
Secrets are not embedded in course HTML or returned to the browser.
Inspect outcomes
Review recent event and destination records and troubleshoot failures.
Provider acceptance is not attribution or a guaranteed analytics-dashboard result.
Build a safe integrationDevelopers and operators
Read the actual contract
Use the generated OpenAPI reference and feature guides to find registered operations and schemas.
Internal modules do not establish a supported public endpoint.
Use the correct identity boundary
The current customer HTTP surface uses browser sessions. Protected writes require Origin and CSRF validation.
Do not collect session cookies to build a third-party server integration.
Respect tenant authority
Go derives the actor and company from the session and checks role/scope on every operation.
A client-provided organisation ID cannot grant authority.
Handle conflicts and retries
Preserve command IDs where documented. Reconcile revision conflicts and ambiguous results before resubmission.
There is no universal exactly-once guarantee for external effects.
Qualify extensions separately
Agree scopes, credentials, event semantics and compatibility before machine access, mobile auth, SCIM or general webhooks.
These are not automatically enabled by the browser API reference.
Operate & recoverPlatform operators
Prepare an installation
Configure canonical HTTPS origins, Go API/worker, PostgreSQL, identity, object storage and the required secrets.
Local host processes and infrastructure containers are separate in development.
Start with compatible versions
Apply approved forward migrations and run matching application binaries. Check readiness and dependency health.
A running homepage does not prove every worker or optional capability is healthy.
Keep keys available
OpenBao-backed key operations must be available for protected data. Investigate failures without bypassing encryption.
Automatic unsealing is deferred; a restart may require manual operator unsealing.
Monitor and investigate
Inspect application/job health and scoped audit evidence. Keep credentials out of logs and support requests.
Provider outages and uncertain external effects need explicit diagnosis.
Prove recovery before rollout
Agree retention, backup protection, restoration tests and operator responsibilities.
Off-server backups remain a TODO. Same-server snapshots do not provide independent disaster recovery.