At a high level, the integration process for all SIS systems 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:
- Coursedog's integration partner delivers bidirectional integration (GET and POST) APIs for the Staging/QA environment. This process usually takes a few weeks
- Coursedog executes QA on the inbound flow of data into Coursedog from the SIS (we call this the GET phase)
- Joint review sessions are executed with you to perform User Acceptance Testing of the GET data on Staging
- Joint validation meetings with you to validate bidirectional data flow (what we call POST data)
- 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.
- Integration partner delivers APIs for Production
- We clone Staging to Production and connect the APIs
- Full QA of GET data on Prod
- Joint testing/validation meetings with the customer to test POSTS
- 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. Coursedog is also in the business of adding courses to a term where the course was not already in the rolled term.
- 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:
- 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.
- 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 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.
- 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.
Note that Blocked Out Times data nearly never comes from the SIS and is set as Coursedog owned.
Variations/Exceptions: No common variations.
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
- 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 'Always Coursedog' or those manually added rooms will be lost the next time the integration runs.
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.
Variations/Exceptions: Banner integrations don't send department status as a field and we set Status as Always Coursedog.
Note: It is important that institutions creating and integrating the course entity between Coursedog and their SIS include Deprecated Coursedog Id as an "Always Coursedog" field. This will ensure that as courses identifiers are updated during the merge process to reconcile courses created in Coursedog with the identifiers assigned by the SIS, any past proposal activity is maintained.
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 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: 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 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:
Note: 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.
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.
There are two primary entities in our curriculum application: Courses and Programs. These entities require careful discussion with your Coursedog implementation team to determine the best approach to data management depending on the capabilities of your integration.
Regardless, the following should be configured: