Table of Contents
Overview
Source of Truth
Integration Timeline
General Integration Rule: Who Owns Which Data?
General Integration Rule: Exceptions
Integration Configuration Recommended Settings
Related Articles
Overview
This article describes the configuration of the Source of Truth (or “Merge Settings”) for all data exchanged between your SIS and Academic Scheduling.
Source of Truth
To view your Source of Truth settings, navigate to: Admin > Merge Settings > Settings > Type-Specific Settings.
The source of truth, or system of record, is configurable on an entity and field-by-field basis, for example:
The call number of a section is defined as an SIS-owned field (the SIS is always the source of truth for the call number).
The classroom that a section meets in is defined as shared ownership between the SIS and Coursedog, with Coursedog serving as the main source of data entry.
Integration Timeline
At a high level, the integration process for every SIS involves bi-directional integration (both GET and POST) being implemented and validated in your Coursedog staging environment, followed by clone and deployment to your production Coursedog environment. Most commonly, the integration timeline is as follows:
Staging
Coursedog's integration partner delivers bidirectional integration (GET and POST) APIs for the Staging/QA environment.
Coursedog executes/validates the APIs and connects them to the staging application.
Coursedog employs the APIs to load data into the platform for data validation by the institution.
Couresdog and the institution collaborate on bi-directional (GET and POST) testing on the staging platform.
You agree to move forward with Production deployment.
Coursedog asks the integration partner to move forward with deployment of necessary scripts needed for provisioning of APIs for your production environment.
Production
Integration partner delivers APIs for Production.
We clone Staging to Production and connect the APIs.
Coursedog merges data into the platform and requests validation by the institution.
Joint smoke testing with the customer to test POSTS.
Sign off.
General Integration Rule: Who Owns Which Data?
While Coursedog is fully configurable to support all types of integration scenarios, as a general rule:
The SIS and Coursedog jointly own the definition of as well as attributes related to sections, with Coursedog being in the business of section creation and section update related to scheduling.
The SIS owns the existence, definition, and attributes/fields of the following entities: terms, buildings, rooms, departments, instructors, and courses. In other words, you won't go into Coursedog to create or update any of these entities.
If you have bad data in the SIS for the above entities, then you will correct it in the SIS.
Example Best Practices
A registrar would not create a room, building, department, or course directly in Coursedog but would do so in the SIS knowing that those creation events would flow from the SIS into Coursedog automatically via the nightly synchronization.
A registrar would not create an instructor or change their last name or assigned departments directly in the Coursedog UI but would go to the SIS to make those changes, again knowing that such changes will flow into Coursedog automatically.
If instructor status information is unreliable in the SIS, then go through a concerted effort to correct it in the SIS. In other words: go through your SIS to correctly identify instructors who have left the institution, deceased, retired, gone on leave, etc.
General Integration Rule: Exceptions
There are two types of exceptions to the general integration rule above:
Internal Coursedog Fields – Coursedog stores additional attributes/fields in and around all entities. These internal fields are never sent to the SIS and will always be listed as exceptions in the screenshots below.
Noted Exceptions – These are fields that the SIS would normally own but will never have good data for AND that you want to update directly in the Coursedog UI so that your schedulers have good information in front of them when making scheduling decisions. Note that only in the case of Sections and Crosslists (and for Banner Linked Sections) are any such field updates ever sent back to the SIS. For example, you could go through a concerted effort to update all room feature information directly in Coursedog knowing that room updates are never sent to the SIS.
Integration Configuration Recommended Settings
Overview | Courses | Relationships | Sections | Professors
Rooms | Departments | Terms | Buildings | Custom Fields
Overview
In a Standard Generic Integration Configuration scenario, the below screenshots demonstrate the recommended Coursedog settings.
With the “Default source of truth” set to “Always Institution”, all attributes/fields of the entity will be 100% owned by the SIS except for the ones listed as owned by Coursedog in the “Field-specific exceptions” box.
Settings will be tailored for each SIS.
If a field is not available to select from the menu of options, scroll to the bottom of the dropdown menu and select “Add Custom Exception”; input the label and path; and then click “Save”.
Courses
Only fields marked as “Always Coursedog” under “field-specific exceptions” should be editable in the Course Template; all other fields should be read-only.
Read-only fields include: Course Code, Course Name, Course Description, Departments, Course Attributes, and Course Status.
You can learn more about configuring templates here.
Variations/Exceptions
Course Notes are set as “Always Coursedog” since it is highly uncommon for SIS systems to have notes data on Courses that are appropriate for Coursedog. If this is untrue for your institution:
Set as “Locked” in the Course Template so that people can view but not edit this field in the Coursedog UI).
Remove it from the “Always Coursedog” field specific exceptions list.
Relationships
The default source of truth for relationships should be set to “Resolve as Coursedog”. Like sections, relationships are bi-directional and for edits made in Coursedog to be sent and persist into the SIS, we require a “Resolve As” selection.
Field-Specific Exceptions
Course Ids –This is an internal field in Coursedog that stores the list of courses involved in the relationship; source of truth should be set to “Always Coursedog”.
Section Numbers – This is an internal field in Coursedog that stores the section IDs involved in the relationship; source of truth should be set to “Always Coursedog”.
Last Edited At, Last Edited By, Created At and Created By – This is internal to Coursedog and does not come from the SIS; source of truth should be set to “Always Coursedog”.
Group Id – Group information comes from the SIS and should be set to “Always Institution”.
Sections
Overview
Sections configuration is less fixed than the other entities given that sections can be edited and created in Coursedog depending on your preferences, and also due to variation in the data SIS systems are able to deliver.
Expected Baseline Configuration
Specify “Default source of truth” to “Resolve as Coursedog”
Specify These Fields as “Always Coursedog”
Specify These Fields as “Always Institution”
Variations/Exceptions
Specify “Default source of truth” to “Resolve as Coursedog”
To use Coursedog for scheduling, Coursedog must be the source of truth.
Please ensure that your schedulers know that to make changes to sections and section schedules, they must do so in Coursedog and that if they make changes directly in the SIS and also in Coursedog within the same day, the Coursedog changes will overwrite those made in the SIS.
As such, Coursedog must be the system of data entry for the fields and attributes that Coursedog owns around sections (i.e. The fields you see in your Coursedog UI).
Specify These Fields as “Always Coursedog”
It is important that institutions creating and integrating the section entity between Coursedog and their SIS include “Deprecated Coursedog Id” as an "Always Coursedog" field. This will ensure that as section identifiers are updated during the merge process to reconcile sections created in Coursedog with the identifiers assigned by the SIS, any past proposal activity is maintained.
Specify These Fields as “Always Institution”
Enrollment, prior enrollment, and call number should always be owned by the SIS (the values for these fields will never be defined or overridden directly in Coursedog).
Variations/Exceptions
There are variations on the above; however, we recommend working with your Customer Success representative to configure your integration appropriately for sections.
Professors
Only fields marked as “Always Coursedog” should be editable in the Instructor Template; all other fields should be read-only.
Read-only fields include: First Name, Last Name, Type, Departments, Status, E-Mail, Bio, Effective Start Date, Effective End Date.
You can learn more about configuring templates here.
Variations/Exceptions
Biographical information is nearly never defined well or at all in the SIS and may be designated as a field-level exception set to “Always Coursedog”.
It can be made editable in the Instructor Template if you wish to enter biographical information directly into Coursedog.
Rooms
Only fields marked as “Always Coursedog” should be editable in the Room Template; all other fields should be read-only.
Read-only fields include: Room Name, Campus, Departments, Building, Room Number, Capacity, Features, Room Type.
You can learn more about configuring templates here.
Variations/Exceptions
Sometimes room feature data in the SIS isn’t great and can't be updated in the SIS in a meaningful way. In this case, set a field specific exception to “Always Coursedog” and make the feature’s field editable in the Room Template.
Sometimes room type isn't good data in the SIS; however, we expect that institutions would update the data in the SIS to clean it up rather than set it as a Coursedog editable field.
Departments
"scheduleValidationWorkflowId" and “smWorkflowStep” must be added using the "Add Custom Exception" option in the fields drop-down.
Variations/Exceptions: Banner integrations don't send department status as a field and we set “Status” as “Always Coursedog”.
Terms
Field-Specific Exceptions
Historical – Coursedog automatically flags terms as historical based on their date compared to the current date. Also, there is a User Interface (UI) checkbox to designate terms as historical in the UI.
Date Exceptions and Conversion Dates – These term profile attributes are configurable in the Coursedog UI only and will never come from the SIS.
Display Name – SIS delivers a “name” attribute and internally we copy that to be the “display name” attribute. As such, this is a Coursedog internal field.
Phase – Phases allow terms to designate different configuration sets. As an internal Coursedog attribute, it must be set to Always Coursedog.
Buildings
Field-Specific Exceptions
Blocked Out Times – Data nearly never comes from the SIS and is set as Coursedog-owned.
Blackout Dates
Available times
Notes
Custom Fields
If you have custom fields on your template that house Coursedog-only data, you will need to ensure you have added those custom fields as a field-specific exception in your merge settings.