SIT Course Builder · Sync to LMS

Confirmation questions — Deploy & Set Up for New Trimester

Thank you for clarifying that Module code stays locked across forks, and that each fork syncs to a new coursesite found by parent Module code + trimester. Below are the remaining points we need confirmed so we can implement Save, Deploy (roster sync), and Set Up for New Trimester consistently.

SIT Course Builder 20 Jul 2026

What we understood from your reply

Terms used below

Module (type 101)
LMS module definition — parent org unit; typically has no student class list.
Coursesite / Course Offering (type 3)
LMS offering under a Module (and semester) — where the student roster lives.
Micro-credential (MC)
Optional Builder field used in Deploy fallback (Priority 2) with trimester.
Course Builder trimester / AY
Managed in Course Builder (not synced from LMS); used for dates and for Deploy search.

1. Trimester / AY code — must it be the 4-digit LMS run code?

Trimesters/AYs are defined manually in Course Builder (not synced from LMS), mainly for start/end dates that drive the deploy / lock window. Deploy, however, searches LMS by Module code + indicated trimester (your example: 2601 ≈ AY 26/27 T1).

Course Builder trimester manual · not from LMS
dates → deploy window
→
Enrolment config trimester selected on module
→
Deploy lookup Module code + trimester
→ LMS coursesite

Course Builder owns the trimester record; LMS still needs a trimester indicator on the coursesite. Those only align if the value stored in Course Builder matches what LMS uses.

Message from Nguyen Thi Tu Linh: trimesters/AYs are not synced from the LMS and must be defined manually in Course Builder; the table defines trimester dates for deploy/lock windows.
Earlier clarification: trimesters/AYs are not synced from LMS and are defined manually in Course Builder (dates drive when a module can be deployed or becomes locked).
Documented 4-digit module-run / trimester code
YYAY start
26 = 2026
+
Ttrimester
1 / 2 / 3
+
0padding
always 0
→
e.g. 2610AY 26/27 T1
2630 = T3 · 2710 = 27/28 T1

Fork to a new trimester creates a new module run with a new trimester code. Note: the chat example used 2601; the format above implies 2610 — please confirm which LMS expects.

If yes Builder code = LMS search key

Create trimesteralways 4-digit
(2610…)
→
Deploysame code used
in LMS search

Admins should not use free-text AY labels if Deploy must match LMS exactly.

If no Display label ≠ LMS key

Builder trimesterdisplay / dates
≠
LMS trimester keyneeds a mapping

Then we need a defined mapping from the Builder trimester to the LMS search value.

Please confirm When creating a trimester in Course Builder, must the code always be the 4-digit LMS-style run code, and is that same code what Deploy sends as the “indicated trimester” in Module code + trimester → coursesite search?

2. Perpetual modules (Sync to LMS, empty trimester)

The dashboard Perpetual section shows modules with Enrolment = Sync to LMS Module and AY / trimester empty. With Deploy resolving roster via Module + trimester → coursesite, an empty trimester means we cannot identify which coursesite (and enrolment list) to use.

Dashboard · Perpetual UI Sync LMS + AY empty
·
Deploy rule Module code + trimester → coursesite
LMS under one Module (type 101)
Module (code locked · no class list)
  • Coursesite · trimester 2610 · roster A
  • Coursesite · trimester 2620 · roster B
  • …

Works Trimester selected

Module Xtype 101
+
Trimester2610
→
Coursesiteroster sync

Open Perpetual · empty

Module Xtype 101
+
Trimesterempty
→
?no roster key
Please confirm For Sync to LMS modules with empty trimester (Perpetual): should Deploy be blocked, skip roster sync, or use another coursesite selection rule that does not need trimester?

3. Micro-credential (MC) code — Module (101) or Course Offering (3)?

One Micro-credential can link to several Course Builder modules (e.g. 3–4). On Deploy, Priority 1 is Module code + trimester; Priority 2 (fallback) is MC code + trimester. We need to know what MC code must match on LMS when admins create an MC.

1 MC shared MC code
→
Builder module Aown Module code
Builder module B…
Builder module C/D…
Deploy Sync to LMS
Priority 1 Module code + trimester
/
Priority 2 MC code + trimester
→
Coursesite roster sync

Priority 1 “Module code” is the LMS Module (type 101) parent, per your clarification. Should Priority 2 “MC code” be the same kind of LMS code, or a Course Offering code?

Reading A Same shape as Priority 1

MC code= LMS Module (101)?
+
Trimester
→
Coursesiteunder that parent

Symmetric with Module + trimester. Please confirm whether one MC (one 101 code) for several Builder modules is intended.

Reading B Earlier MC confirmation

MC code= Offering (type 3)
→
Exact matchLMS Course Offering

Earlier discussion: for Priority 2 fallback, MC codes in Course Builder need to exact-match LMS Course Offering codes.

Discussion confirming MC codes created in Course Builder must exact-match LMS Course Offering codes for Deploy Priority 2 fallback.
Earlier confirmation: MC code must exact-match the LMS Course Offering code for Priority 2 fallback.
Please confirm When creating an MC, should MC code match an LMS Module (type 101) code or an LMS Course Offering (type 3) code? If it is type 3, how should “MC code + trimester” work (an Offering already points to one coursesite)?

4. Who can use Set Up for New Trimester (fork)?

As confirmed: fork clones the module, keeps Module code, uses a new trimester, then Deploy finds the matching new coursesite. We still need which modules are allowed to fork — including modules under an MC.

Option Any module

SIT / Public
Sync LMS
± trimester
→
Fork allowed?

LMS coursesite rules would apply only when enrolment type is Sync to LMS.

Option Sync LMS + trimester only

Sync to LMS
+
Trimester set
→
Fork allowed
otherwise
SIT / Public / Perpetualfork not available?
When Deploy uses MC + trimester (Priority 2)
MC MC code + trimester
→ LMS coursesite
→
Builder module A
Builder module B
Builder module C/D
Can A / B / C each be forked on their own?

If yes Per-module fork

A → A′same Module code
new trimester
B → B′same…

Do forked runs stay under the same MC? Deploy still Priority 1 then Priority 2?

If no Restricted

Children cannot fork alone
/
Fork only at MC level?if that exists
Please confirm (1) Which modules may use Set Up for New Trimester — any enrolment type, or only Sync to LMS with a trimester?
(2) When several Builder modules sit under one MC used for enrolment: can each module be forked independently (clone + same Module code + new trimester)?

5. Deploy lookup — is Module/MC + trimester always unique?

Deploy searches for a coursesite by Module code + trimester (or MC code + trimester). The happy path assumes exactly one match. Please confirm whether LMS can return more than one.

First question

A Always unique

By LMS design, Module (or MC) + trimester returns at most one coursesite. Then we only need behaviour when none is found.

B Multiple possible

The same parent + trimester can match more than one coursesite. Only then do we need a multi-match rule.

Only if B — how should Deploy handle results?
Searchcode + trimester
→
0block + message?
1sync roster
Nfail / user pick / rule?

If A (unique), we can ignore the N branch and only confirm the “not found” experience.

Please confirm Is Module+trimester (and MC+trimester) guaranteed unique on LMS? If yes → please confirm behaviour when no coursesite is found. If no → please define how Deploy should handle multiple matches.

6. Save — LMS verify target & duplicate Module code with forks

Save (Sync to LMS) today is described as: verify Module code on LMS (if that fails, try MC), show reference info, and block if the Module code already exists in Course Builder. With Module code = LMS Module (type 101) and the same code kept on every fork, we need the Save rules to match that model.

Save (current description)

  • Verify “Module Code” on LMS (else MC)
  • Show Module Name / Cluster / Programme
  • Block if Module Code already exists in Course Builder

Model you confirmed

  • UI Module code = LMS Module (type 101)
  • Same code kept on every fork
  • Coursesite chosen later via + trimester
points to align
LMS verify target Module (101) only?
or also Offering?
Duplicate check Global unique code
would block fork v2
if v1 already uses X
Please confirm (1) On Save, should LMS verification look up Module (type 101) only, or something else?
(2) For “A module with this Module Code already exists” — should uniqueness allow the same Module code across versions in the same lineage (so fork is not blocked), or another rule you prefer?