Table of Contents
Overview
When It Should Be Used
When It Shouldn’t Be Used
Expected Behavior
Supported Entities
How to Use It
Scheduling - Additional Details
Curriculum - Additional Details
Allow Integration vs. Object Merge Settings
Related Articles
Overview
Templates in both Curriculum and Scheduling products include a pre-built field called “Allow Integration” that allows a user to determine whether or not individual records POST to the SIS.
This might appear in your user interface (UI) as either “Allow Integration” or “Allow Integration Sync to SIS”.
The field can be used to prevent POSTs, but it does NOT change the default source of truth for the merge that determines which data should be retained. That setting can be controlled at the record-level by using Object Merge Settings.
When It Should Be Used
The “Allow Integration” field should be added to:
Course and program templates for Curriculum integrations that support POSTs.
Section templates in Scheduling if you wish to selectively turn off integrations for certain sections.
When It Shouldn’t Be Used
You don’t need to use this field for CSV or GET-only integrations.
Expected Behavior
When “Allow Integration” is "Yes", updates will be sent to the SIS for that record.
When “Allow Integration” is "No", updates will NOT send back to the SIS for that record.
The default setting for this field is null/blank. When “Allow Integration” is not set or not on the form:
Within Curriculum this will be treated as “NO”, and no updates will be sent to the SIS for that record.
In Academic Scheduling this will be treated as “YES”, and updates will be sent.
Allow Integration operating as “NO” means that the synchronization step to post to the SIS will not run. Consider that if edits are made to an entity but not posted to the SIS then on the next merge with the SIS, those edits could be overwritten by SIS data unless the fields are designated as Always Coursedog. In other words, it is important to consider the configuration of Allow Integration with respect to the field source of truth configuration within Admin > Merge Settings.
If the field defaults to “Yes”, each course won’t post every night; rather, the merge runs a GET first, compares it to Coursedog data, and determines whether or not anything needs to POST.
Supported Entities
The supported entities are outlined below by product.
Curriculum - Courses & Programs
You can access and add the pre-built “Allow Integration Sync to SIS” field within the Course & Program templates and forms.
Note on exception: Within Curriculum for Programs and Courses, no updates will be sent back to the SIS for that entity if “Allow Integration” is not explicitly yes (thus, empty/blank will prevent an update for the entity to be sent back to the SIS).
Scheduling - Sections
You can access and add the pre-built “Allow Integration” field within the Section Template (Settings > Templates > Section Template).
How to Use It
Adding it to Your Template
Open the template you wish to add the field to.
Click prebuilt fields in the Question Bank.
Drag and drop “Allow Integration (Sync to SIS)” onto your template.
Click into the field to modify its settings.
You can set a default value of “Yes” or “No” to be applied when no value exists. Learn more here.
Using it within a Course/Program/Section Record
If you’re completing direct edits to a course/program/section, the best way to ensure the updates are sent to the SIS is to set “Allow Integration” to “Yes”. This will stay set as “Yes” and will send updates in a nightly merge so long as “Allow Integration” is set to “Always Coursedog” in exceptions.
Scheduling - Additional Details
The primary use case for using the “Allow Integration” field in the Section Template is to outline whether or not a specific section (and its accompanying relationship, if any) should be POSTed to the SIS.
In other words, certain institutions may wish to have the ability to selectively turn off sending back section/relationship updates for specific sections while still keeping those sections in Coursedog. In this instance, the institution should add the “Allow Integration” field to the Section Template (Settings > Section Template). Users will then be able to designate an entity (Section) record to be excluded from the POST integration by navigating to this section in the Section Editor and toggling the “Allow Integration” field to NO. This will result in this section NOT being considered as part of the merge data set, and the section will persist in Coursedog despite not existing in the SIS.
Note that, if “Allow Integration” is blank (or not included in the form), the default behavior is to send updates back to the SIS for that entity (i.e. treated as “true”).
Curriculum - Additional Details
Learn more about using this field in Curriculum here.
Allow Integration vs. Object Merge Settings
“Allow Integration” and “Object Merge Settings” are both prebuilt fields that can be added to templates.
These are two different options that can be used together to help you get your desired outcome.
“Allow Integration” filters for whether or not an individual record will POST.
“Object Merge Settings” gives you record-level control of the Default Source of Truth. In other words, you can use “Object Merge Settings” to say “For this individual record, always resolve as _____.”
Additionally, “Object merge settings” can be used for GET-only entities like Rooms (this allows you to maintain a list of rooms in Coursedog beyond what exists in the SIS by resolving those rooms as “Always Coursedog” to prevent them from getting wiped in a merge). For example: If you add a Room in Events that doesn’t exist in the SIS and don’t set the individual merge settings for that room as “Always Coursedog”, then it will be wiped in the next merge.
Learn more about Object Merge Settings here.