Cross-listed sections are multiple sections intentionally linked because they are taught as a shared instructional experience, while students enroll under different section numbers, subject codes, or Departments. In the platform, one section is designated as the parent (the primary section and roll-up target), and the others are child (linked) sections. Cross-listing is configured at the course section and co-curricular section levels. In the platform, Institutions can cross-list sections, but not courses or co-curricular activities.
In cross-listing, one section is designated as the parent. The parent is the primary section for key workflows and reporting and serves as the roll-up target. The other sections are the child (or linked) sections. Child sections remain their own sections, but their data rolls up to the parent. With cross-listed sections, Institutions typically run one evaluation process managed by the Department that owns the parent section, and results are aggregated to the parent.
Use Cases
|
Combined Course Evaluation Reporting |
|
A course is offered as multiple sections (often across Departments or subject codes) but is taught as a single shared experience, and the Institution wants one consolidated set of course evaluation results. Cross-listing allows the evaluation to be managed from the parent section, with linked child sections included in a single reporting output. |
|
Anonymity Protection for Small Sections |
|
One section has very low enrollment (for example, an honors discussion or graduate seminar), which can make student feedback identifiable and can also cause minimum response thresholds to block reporting. By cross-listing that small section into a higher-enrollment parent section, feedback and results can be aggregated, allowing reporting to remain usable while better protecting student anonymity. |
|
Streamlined Assessment and Assignment Linking |
|
Multiple sections share the same instructional content and assignments (commonly because they use a shared LMS course shell), and the Institution wants outcomes assessment to follow the “one course, one set of assignments” reality. Cross-listing sections supports more centralized management of assessment work by treating one section as the parent, reducing duplicate setup and keeping scoring and assessment results aligned with how the course is actually delivered. |
|
Co-Curricular Programs With Multiple Cohorts or Sessions |
|
A co-curricular activity is run in parallel sections (e.g., multiple workshop cohorts, internship cohorts, or repeated sessions), but stakeholders want to evaluate the experience as a single activity. Cross-listing co-curricular sections allows those related sections to roll up to a parent section for more cohesive assessment, evaluation, and reporting across the full activity. |
How Can Cross-Listing Happen?
|
Method |
Information |
|
SIS/Data Files |
Recommended. Sent via nightly data files indicating a parent/child relationship between the sections. Cross-listing details can be provided with the Course Section data file using the optional parent fields. The parent course section must also exist in the platform, which generally means it must be provided through data files (not just created in the LMS). With this method, the platform performs an hourly check for cross-listed sections that are part of assessments and associated with pending, active, or in-progress terms. |
|
Platform UI |
Manual. This functionality must be enabled by HelioCampus. Institutions should contact Support for more information. If enabled, sections can be manually cross-listed directly in the platform using the Link Sections action from the section homepage. This method is most useful for urgent one-off exceptions when the SIS/data files cannot be updated quickly. |
|
LMS |
LMS-Managed. This method only affects assessments in the platform, unlike SIS/data file or platform UI methods, which affect areas such as surveys/syllabi/etc. Scoring occurs in the LMS using this method, which means all scores are stored in the parent. |
Manual vs. Data File Cross-Listing
In most cases, the data file method is the best long-term approach because it is consistent and scalable across terms. Manual cross-linking in the UI is most useful for urgent timing needs or one-off exceptions when the SIS/data files cannot be updated quickly.
|
|
Platform UI |
Data File |
|---|---|---|
|
Reason |
Urgent fixes or one-off exceptions |
Long-term, repeatable cross-listing as a standard institutional practice |
|
Speed |
Fastest. Can be done immediately once enabled by HelioCampus |
Depends on when files are updated and processed (at least next import) |
|
Who |
When enabled:
|
IT/SIS team |
|
Effort |
Low for a few sections |
Higher upfront, but lower ongoing effort once built |
|
Scalability |
Not ideal at scale (manual work grows with volume) |
Scales well across many sections/terms |
|
Consistency |
Risk of drift if the SIS/data files remain the “source of truth” but do not match the manual links |
Most consistent if the SIS feed is the system of record |
|
Downside |
Can be overwritten or become confusing if the SIS/data files later send different relationships |
Slower to respond to last-minute changes; depends on when files are updated and processed (at least next import) |
|
Recommendation |
Use for exceptions and emergencies |
Use as the default method whenever possible |