Coursedog

Submit a ticket My Tickets
Welcome
Login  Sign up

All SIS: Standard Integration Configuration for Class Scheduling

Overview

At a high level, the integration process for all SIS involves GETs and POSTs both being implemented and QA’d in Staging, which is then followed by a singular push to Production. Most commonly, the integration timeline is as follows:


  1. Staging
    1. Third party integration partner (i.e.: N2N) delivers both the GET and POST Staging APIs in one go.  This process to get the client system configured and the APIs delivered usually takes a few weeks
    2. Coursedog executes QA of GET data
    3. Do joint review session with client to execute UAT of GET data on Staging
    4. Joint validation meetings with the client to validate POST data
    5. Client agrees to move forward with Production deployment. Coursedog asks the integration partner (i.e.: N2N) to move forward with deployment
  2. Production
    1. Integration partner (i.e.: N2N) delivers APIs for Production
    2. We clone Staging to Production and connect the APIs
    3. Full QA of GET data on Prod
    4. Joint testing/validation meetings with the customer to test POSTS
    5. Sign off


This article describes the configuration of the Source of Truth (or 'Merge Settings') for all data exchanged between the SIS and Coursedog. The source of truth, or system of record, is configurable on a 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 as the main source of data entry


To view your Source of Truth settings, navigate to the Admin panel, and select 'Merge Settings' from the left-hand navigation. Then scroll down to the 'Type-Specific Settings' card.

General Integration Rule

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 and 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
    • For example, 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.
    • I.e. 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.
    • I.e. If instructor status information is unreliable in the SIS then go through a concerted effort to correct it in the SIS —to designate instructors who have left the institution, deceased, retired, gone on leave etc. correctly in the SIS.

Exceptions to the General Integration Rule

There are two types of exceptions to the general integration rule above:

  1. 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.
  2. 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 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

In a Standard Integration Configuration scenario the following screenshots demonstrate the recommended Coursedog settings. With the 'Default source of truthset 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.


Terms

  • Historical:  Coursedog automatically flags terms as historical based on their date compared to the current date.  Also, there is a 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.

Variations/Exceptions: No common variations.


Buildings


Note that Blocked Out Times data nearly never comes from the SIS and is set as Coursedog owned.

Variations/Exceptions: No common variations.


Rooms

To enforce that the SIS owns the following room fields they should be set as non-editable in the Room Template which is the UI/form for editing rooms in Coursedog: Room Name, Campus, Departments, Building, Room Number, Capacity, Features, Room Type

For Example:

Variations/Exceptions:

  • Sometimes room features are just not great data in the SIS and 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 features 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.
  • In rare cases there are rooms at the institution that the SIS cannot or will never know about. Those rooms could be added manually through the UI in Coursedog or uploaded/imported. To add them manually you'll need to set the Room Template fields as editable while creating them. You should also change the Default source of truth from 'Always Institution' to 'Resolve as Institution' to better configure the system to recognize that the SIS is not the absolute source of truth on Rooms.

Professors


To enforce that the SIS owns all instructor attributes/fields except those listed as exceptions above, the following Instructor Template fields should be set as non-editable: First Name, Last Name, Type, Departments, Status, E-Mail, Bio, Effective Start Date, Effective End Date


Variations/Exceptions: Bio 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' and made editable in the Instructor Template if you wish to enter bio information directly into Coursedog.


Departments

Variations/Exceptions: No common variations.

Courses

Furthermore, to enforce that the SIS owns all course attributes/fields except those listed as exceptions the following Course Template fields should be set as non-editable (locked):

Variations/Exceptions: Course Notes are set as Always Coursedog in the above screenshot 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 then set as 'Locked' in the Course Template (so that people can view but not edit this field in the Coursedog UI) and remove it from the 'Always Coursedog' field specific exceptions list.

Sections

Sections configuration is less fixed than the other entities above 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. The following, however, is the expected baseline configuration:


Specify default to Resolve as Coursedog: While you are using 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 that they must do so in Coursedog and that if they make changes directly in the SIS and also in Coursedog within the same day that 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 —essentially the fields you see in the UI in Coursedog.


Specify these fields as Always Coursedog:


These fields 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.

C
Coursedog is the author of this solution article.

Did you find it helpful? Yes No

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