Coursedog

Submit a Ticket My Tickets
Welcome
Login  Sign up

COURSES: Setting Up the Course Template

Table of Contents

Overview
Example Course Template
Custom Fields
Course Template Fields
Question Settings
Shared Department Ownership
Automatically Generated Cards
Related Articles

Overview

LOCATION: Curriculum > Settings > Course Template

  • The course template defines the basic set of information that constitutes a course. 

  • It is often determined by making sure that the fields map with an institution's student information system, in addition to any fields that may be handled outside of the SIS. 

  • It uses the same drag and drop form builder that is described in Managing Curriculum Forms

  • The template’s question bank consists of two types of questions that can be added to the template: Custom Fields and Course Template Fields. 

Example Course Template

An example course template could include:


Subject Code

Course Number

Course Title

Department(s)

College/School

Start Term

End Term

Description

Topics

Campus (Single select)

Campuses (Multi select)

Files

Learning Outcomes

Syllabi

Credits (Fixed, Variable, etc.)

Requirements

Custom Fields

  • Custom fields can be added to the template by dragging and dropping “custom fields” from the question bank. 

  • All custom questions added to the course and program template are assumed to be “Coursedog-only” content, and by default are not integrated unless a specific exception is made in the integration wiring.

  • Once added, click into a field to modify its Question Settings. 

Course Template Fields

Overview | Primary and Graded Component (PeopleSoft)
Course Aliases | CIP Code and Hegis Code | Course Attributes Field
Course Equivalencies | Catalog Print

Overview

  • “Course Template Fields” are delivered, prebuilt fields.

  • These can't be adjusted to have the "single" or "multiple" value changed. In these cases, we advise that the client create custom fields or arrange for an enhancement. 


Primary and Graded Component (PeopleSoft)

  • Primary Component and Graded Component are fields built for PeopleSoft customers. These are stored at the course level, rather than within the pre-built Components card. The options shown on the drop-downs for these fields are automatically fetched from the available components on a given course (i.e. the Component Name fields for that course, as defined in the pre-built Components card). If a component doesn’t have a name, it will not show up on the drop-down list. The drop-down is updated in real time (i.e. if a user edits the course and adds a Component Name, this new name will immediately show up as an option in the Primary/Graded Component drop-downs).

  • If “Optional Component = Yes”, then the component is not displayed as an option in the “Primary Component” and “Graded Component” fields. This change prevents Course POST errors and prevents end users from accidentally selecting “optional components” as “primary components” and “graded components”. This behavior enhancement is aligned with how the fields operate in PeopleSoft. 

  • In the below example, we have set up two components. One has “Optional Component = Yes” and the other has “Optional Component = No”.


Only the Lecture component is available for selection as the primary component or the graded component. 

Course Aliases

  • There is a prebuilt field labeled "course aliases." This input is only allowed once in the Course Template and in the Form.

  • Aliases are when Courses can have multiple different Course Codes (as a reminder, what is called the Course Code is usually just an institution's way of saying Subject Code + Course Number, so MATH101 is a course code).

  • Some courses might have multiple course codes. An example of which is BIOCHEM101.

    • This course is a Biology Chem course, offered in the Biology department. However, chemistry majors call this course CHEM101, so it can stay consistent with the fact that Chemistry majors must take CHEM courses. In other words, these students take the same class, but for reporting purposes, they have different names. 


CIP Code and Hegis Code

  • Options for these fields are loaded in from the integration. 

  • The value is stored as the actual code of the data: "CIP Code" or "Hegis Code" (e.g. 05.0206).

  • In the Course/Program page, we will display the "code + description" for users to make it more readable. This only occurs in the Course/Program page, and any reports of curriculum data will only show the code. 


Course Attributes Field

Overview

  • The course attributes pre-built field is aware of effective dating.

  • The field refetches attributes when users define effective dating in a proposal (terms/dates). As such, when a user is creating a proposal, the list of available attributes selectable in the course attributes field will change based on their input in the effective date fields.


Caveat

  • If you wish to add course attributes BUT do not have effective-dated attributes AND/OR have not integrated these attribute details in your instance (Banner, homegrown SIS, etc.), you must use a custom question with type = select instead of the pre-built attributes question.

  • Using the pre-built question in these scenarios could result in data loss.


Course Equivalencies

  • Different institutions have different use cases for this field, but it is often used to flag replacement Courses for ones being added / removed from Curriculum. In other words: If a student returns to the institution after a long gap, which classes they took are equivalent to ones offered today? 

  • Equivalent Courses are NOT the same as Cross-Listed Courses. Instead, think of “Equivalent Courses” as courses that are similar enough to replace one of the other when applicable. 

  • This is most relevant to Ellucian Colleague and Ellucian Banner institutions but has also been used by Jenzabar One.

  • Work with your Customer Success contacts for guidance with using this field.


Catalog Print

  • This field has no meaningful functionality and does not impact catalog visibility, though you can use it for filtering purposes. 

  • This field is integrated for PeopleSoft. 

Question Settings

Overview | “Select” Question Types | Actions

Overview

Click into any field on your template to access and configure its Question Settings.

“Select” Question Types

  • If you add a “Select” Question Type to your Course Template, Question Settings will include an option to “Set Dynamic Options from Attribute Mappings”. 

  • Learn more about that setting here.


Actions

  • Actions generally work the same in Curriculum Management, Academic Scheduling, and Catalog.

  • You can find a general overview of how Actions work – and how to set them up – here.

  • In Curriculum, you can also configure actions (in pre-built select fields with a dedicated merge) to limit which options downstream-users see based on other selected fields in the template. See how that works here.


Shared Department Ownership

You can add a combination of prebuilt and custom fields to the Course Template in order to  accommodate multiple levels of department and college ownership. Learn how to set that up here.

Automatically Generated Cards

Overview | Course Schedule | Dependencies | Learning Outcomes

Overview

  • The course template has the following prebuilt cards, which are automatically generated: Learning Outcomes, Credits, Topics, Components, Course Schedule, Requirements, Dependencies, and Instructional Methods. 

  • These automatically generated cards can have any combination of field settings, advanced settings and/or visibility settings.

Course Schedule

  • The “Course Schedule Card” enables the course schedule to appear when viewing a course. 

  • This card pulls data from Coursedog. Learn more here

  • The course schedule won’t appear in proposals. Learn more here


Dependencies

For schools that don't utilize our requisite builder, we have implemented the ability to hide the "dependencies" card. This can be set by navigating to the template, clicking the eye icon in the "dependencies" card, then modifying visibility settings.


Learning Outcomes

Defining a Required Number | User Error Alert | Tags

Defining a Required Number

Users are able to define a required number of learning outcomes in a proposal. This can be accessed by: 

  1. Accessing the “Learning Outcomes” card in the template.

  2. Click into it to open its question settings.

  3. Checking the “is required” box.

  4. Define the number of required elements in the box that appears.

User Error Alert

  • If you check the “use error alert” box in Question Settings, this will result in validation errors appearing in a large flag at the top of the card.

  • In the below example, because the end user has only created one learning outcome, the error is shown alerting the user that they need two learning outcomes. 

Tags

You can add tag options by clicking the gear icon (advanced settings) on the Learning Outcomes card and then clicking “+ Option” in the “Advanced Settings for Learning Outcomes” modal. 

Related Articles

Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.