Table of Contents
Overview | Finding the Admin Dashboard | Settings | Product Settings
System Health Check | Public Event Settings | Public Catalog Settings
Logo & Styling | User Activity | Data Seeds – INTERNAL COURSEDOG TOOL
CSV Data Upload | Execute Merge | Merge Dashboard | Merge Reports
Restore Past Data | Merge Notifications | Integration Health Check
Merge Settings | Integration Attribute Mappings | Integration Filters
Demand Analytics | Catalog URLs | New Revision Behavior
Data Migrations | Related Links
Overview
Access to the Admin Dashboard is limited to the internal Coursedog team as well as Super Admin users with the Admin product.
The Admin dashboard will primarily be used for:
Adjusting general settings (including SSO and pushing global settings to "children")
Managing product settings
System and integration health checks
Public sites settings (i.e. public-facing sites for Events and Catalog)
Adding a university logo to your interface
Viewing user activity
CSV data uploads (only for institutions with a regular need)
Executing merges (Ad hoc)
Adjusting merge / integration settings
Reviewing merge reports for integration issues
Catalog URLs (only for institutions using Catalog)
A PDF version of this article is attached here, so you can download and/or print if you prefer.
You can also check out Integration Best Practices (Webinar).
Finding the Admin Dashboard
Simply log into Coursedog and click on the "Admin" option (circled below):
Settings
Overview
The settings page is used to view/define several high-level settings.
Notable features include the ability to update SSO/Auth Settings, and, if a system school, set global settings that can be pushed to “children” instances.
It is split between General Settings, System Settings, and Auth Settings.
Only a user with the Coursedog role can edit the Official Name, the Display Name, Email Notification Settings, Does this School Oversee a System of Schools, and Child Institutions. If you’re a Super Admin and you wish to modify any of these settings, please reach out to your Coursedog contact.
General Settings
School Unique ID
View your school’s unique, read-only identifier.
Display Name
View/change the name that is displayed to users inside your instance.
Show Display Name in Sidebar
Determines if your display name is shown in the Top Left of the Navigation Bar.
Email Notification Setting
Determines whether or not end users at your institution can receive email notifications.
If set to “Yes”, there will be further opportunities to customize within each product and for each user.
If set to “No”, that setting could potentially be overwritten for some contacts if "Send email notifications" is set to "Yes" in their profile. This applies to Event Contacts, Organization Contacts, Room Contacts, and Resource Contacts. This is because an Event or Org contact could be outside the institution and will need to be notified of Event creation and/or changes.
If a user signs up for Merge Notifications, they will receive those notification emails regardless of the “Email Notification Setting”.
If you need to change this setting, please reach out to your Coursedog contact (Project Manager or Customer Success Manager), as it can only be modified internally.
System Settings
If toggled to “Yes” for system schools, multiple options will appear.
Push Settings to Children
Clicking this button will push globally defined settings to all child instances.
Any campus-specific configurations of the selected feature will be overwritten.
The system will show a pop-up at the bottom of the screen, indicating action was successful.
Settings to Override
Institutions with Admins managing “children” should keep the below items in the “Settings to Override” (Global Settings):
Section Template
Merge Settings
Current Scheduling Term
Integration Schedule (used to denote real-time integration cadence)
If you would like to override additional system-wide settings, you can select any of the following additional options from the drop-down: Roles, Future Actions, Terms, Date Exceptions, Conversion Dates, Current Term, Standard Meeting Patterns, Integration Attribute Mappings, Instructor Template, Scheduling Room Template, Event Room Template, Course Template (Curriculum), Program Template (Curriculum), Course Template (Catalog), Program Template (Catalog), Course Fields (Scheduling), Approval Workflows, Scheduling Request Settings, Rules, Filters, Notification Events, Event Types, Event Global Blackout Dates, Public Event Settings.
Auth Settings
Use this area to change SSO settings.
Learn more here.
Product Settings
Overview | Default Dating Method | Enable Effective End Date Filters
Restrict Professors Behind Authentication | Restrict Scheduling Courses to Integrated Courses Only
Load Requests from Child Institutions (For Reports Only) | Tooltips, Flows, and Widgets
Fetch Requisites Using Latest Revision Even If Future Dated
Fetch Courses in Degree Maps Using Latest Revision Even If Future Dated
Display Requisite Entity ID Inline if Entity Not Found
Changes Diff: Sort Fields in Form Order
Display All Course and Program Revisions as Dependencies
Filter Out Deleted Attributes from Attributes List
Overview
There are cross-product settings in the Admin Panel that help dictate how different Coursedog products work.
Default Dating Method
This determines whether the “Select Effective Dating” display will default to “Dates” or “Terms” in Curriculum pages for effective dated objects (e.g. Courses, Programs, Requirement Sets).
This is entirely at the customer’s discretion; institutions can select whichever one makes the most sense for them.
Enable Effective End Date Filters
Enabling the effective end date filters will impact how two effective dating “lookups” operate in Curriculum Management and Catalog. Learn more here.
If this setting is set to "No", end date filters might still be present in the application, but will not be functional for filtering purposes
Restrict Professors Behind Authentication
This feature can help prevent potentially sensitive faculty data from being accessed by the public.
Turning this on means that all professor endpoints to load professor data require authentication.
The impact of setting this setting to “Yes” means that professor data CANNOT be loaded in the public catalog, public events, or public preference forms.
Use Case
If an institution lists “Family Medical Leave” as an option for instructor leave, you will want to prevent that information from being accessible by the public.
Restrict Scheduling Courses to Integrated Courses Only
This toggle is relevant in the context of “Adding Courses from Inventory” in Academic Scheduling.
For integrated institutions, this must be set to YES to only make “Integrated Courses” available. If set to YES, courses that exist in Coursedog but do not exist in the SIS will NOT be available.
If this toggle is set to YES (i.e. can only load integrated courses), then the course must have the customFields.rawCourseId field.
You can learn more about adding courses to Academic Scheduling from the Curriculum inventory here.
Load Requests from Child Institutions (For Reports Only)
This setting allows for the “Request CSV/PDF” reports to pull data from all child schools.
This setting is only relevant to institutions that are part of a system with child instances that fall under the system’s Coursedog instance (i.e. not relevant for most institutions).
Tooltips, Flows, and Widgets
We have tooltips, flows, and other educational content throughout our platform in order to provide users with guidance when and where they need it. You can enable (”Yes”) or disable (”No”) that content here, but we recommend keeping this set to “Yes” in order to provide your users with helpful, contextual assistance.
Fetch Requisites Using Latest Revision Even If Future Dated
Overview
This toggle can impact both Curriculum as well as Catalog.
Curriculum
Setting this to “yes” makes it so that when building requirements for a program or course, the query returns the latest course revision, even if future dated.
For example, if you have a program that is set to effectiveStart Fall 2010 and a user builds out a requirement using the course effective dating to be set to start in Fall 2021, then a user later revises the requirement course and the revision has an effective date of Fall 2022, the program will automatically update based on this revision.
If you turn on this feature, this change will be reflected in simple and freeform requisite builders, course / program select, and course / program select in WYSIWYG builders.
Please discuss with your CSM prior to enabling this feature.
Catalog
When activated, there may be discrepancies between the latest revision in Curriculum Management and on the public Catalog website. This is because courses can be added to the curriculum template when they are future dated in this scenario, but the live catalog has a current-day effective date filter, so it will not capture them.
Fetch Courses in Degree Maps Using Latest Revision Even If Future Dated
Setting this toggle to “Yes” will allow future-dated courses to be fetched in Curriculum Management. Learn more here.
Display Requisite Entity ID Inline if Entity Not Found
Set to “yes” if you would like for the Entity ID to appear in Curriculum and Catalog whenever the entity name is not found in the Requirements display.
Changes Diff: Sort Fields in Form Order
If set to “yes,” when viewing proposal changes, the fields will match the order in which they appear on the Form. When set to “no”, fields will sort alphabetically.
Display All Course and Program Revisions as Dependencies
When enabled, all courses or programs revisions for a given group will be displayed as a dependency; otherwise, only the latest revision will be shown.
Please discuss with your Coursedog contact before enabling.
Filter Out Deleted Attributes from Attributes List
This setting applies to schools who use effective dating for Course Attributes (e.g. PeopleSoft schools).
This should be set to “No” by default and set to “Yes” in nuanced situations where you have a Course Attribute Group that had a Course Attribute value removed in later effective rows.
When enabled for those nuances situations, this setting will prevent deleted Course Attributes from appearing.
System Health Check
The System Health Check executes pre-built health checks for the configuration inside an account, across the product suite. The System Health Check can look at workflows, for example, to make sure assigned steps are in-tact. You should review this regularly (e.g. monthly) and resolve any warnings.
Public Event Settings
You can adjust public event settings under the Admin UI or in the Events Application > Settings. For a more in-depth breakdown, visit here.
Public Catalog Settings
You can adjust public catalog settings and design under the Admin UI or in the Catalog Application > Settings. For a more in-depth breakdown, visit here.
Logo & Styling
This page is used to set the Logo in the top-left corner of the internal application.
User Activity
Overview | Tracked Fields | Adding Filters
Overview
The user activity log, also called the “audit log”, allows you to audit system-wide user activity.
Activity includes field-level descriptions of changes and can be filtered by actions and dates.
This can be particularly useful when you need to troubleshoot or verify why settings or configurations have been modified – and possibly make adjustments if changes were made in error.
Tracked Fields
For a complete list of tracked fields, click “Filter” and then click into the “Action” dropdown.
Note that “Edit Section Template v2” is included in the dropdown. Any changes to any field in the Section Template should trigger an update to the User Activity log.
Adding Filters
Overview
When you first land on the User Activity page, you will see a complete list of all tracked activities.
If you wish to see certain types of activity and/or changes for a given date range, you can add filters.
Adding Filters
Step 1: Click “Filter” in the upper righthand corner of your screen.
Step 2 (Optional): Enter a start date and/or end date.
Step 3 (Optional):
Select the action(s) you’d like to see from the dropdown menu.
You can select multiple actions.
You can also access this dropdown menu to see all tracked actions.
Data Seeds – INTERNAL COURSEDOG TOOL
This is an internal Coursedog tool for early stages of onboarding only. Admins should NOT update/change/explore/test this feature without a Coursedog team member - it will WIPE OUT ALL DATA in your environment.
CSV Data Upload
To be used only by institutions who will regularly be updating data like Resources or Organizations (separate training and guides can be provided). CSV uploads are typically rare, in which case: Go through Coursedog Support rather than using this Dashboard tool.
Execute Merge
Overview | Key Points to Be Aware Of | How to Do It | Threshold Detection Merge Setting
Overview
This page is used regularly by Admins and the Coursedog team to bring data into Coursedog (GETs) and to push data back to the SIS (POSTs) ad hoc, as needed.
It’s best practice to engage Coursedog services to run merges or have a technical member of your staff, fully trained by Coursedog, singularly own this feature should you prefer to own it more “in-house”.
Key Points to Be Aware Of
The configuration appearing in Execute Merge comes from the global defaults in Merge Settings. If you change the settings here they will not “stick” once you navigate away from this module - they will revert back to the global settings.
Merges will time out in your browser after 20 minutes and pop up a “Failed” message; however, the merge is still running as a background process. If you don't see a merge report in the Merge Reports screen, then it's still running in the background and you must wait for it to complete prior to running another merge for the same data.
Do not run another merge for the same entity in the same term while an existing one is running. Overlapping merges may cause data anomalies.
- Running a manual merge when users are actively scheduling could trigger a real-time update, resulting in either a duplicate operation or potentially even data loss (there’s a risk that whatever you created would disappear from Coursedog). To avoid this happening with any SIS, we advise against running manual merges when users are scheduling.
If a duplicate operation occurs, rest assured the data will be re-synced by the next nightly merge, so you would see the data in Coursedog and could adjust accordingly.
If what you created disappears from Coursedog, it will get pulled in on the next run but will be missing any Coursedog-only data.
How to Do It
Follow the below steps to execute a manual merge.
Step 1:
Navigate to Admin Panel > Execute Merge.
NOTE: Ensure you are on the “Execute Merge” page before proceeding; changes made on the “Execute Merge” are one-time changes and should not be made on the “Merge Settings” page.
Step 2:
Select the entity (e.g. Sections) from the “Select Type” dropdown menu and Term (e.g. Spring 2022) from the “Select Term” dropdown.
Click “EXECUTE”.
Step 3:
Now that the section data is loaded, you will need to load in the initial course data into the new term.
Follow the exact actions outlined in Step 2, except select “Courses” instead of “Sections”.
Step 4:
Now that the section and course data is loaded, you will need to load in the initial relationship data into the new term.
Follow the exact actions outlined in Step 2, except select “Relationships” instead of “Sections”.
Threshold Detection Merge Setting
When sections, programs, relationships, events, or Courses (curriculum) is selected as the “Select Type” dropdown and “Should Coursedog send updates to SIS” is set to “yes”, on the Execute Merge screen, you will see an additional setting called “Should updates be sent to the SIS when there are more than 100 entities with changes”?
This is always set to “No” for nightly merges (in other words, in nightly merges updates won’t be sent to the SIS when there are more than 100 entities with changes).
This is a protective measure that will prevent a merge from completing if the number of entities updated is above the configured threshold (100 entities).
This is intended to limit unintentional widespread updates within the SIS.
If needed, you can remove this protective measure for manual merges by switching this setting to “yes”.
Setting this to “Yes” will remove the protection for a manual merge and all updates, assuming no other complications, will be sent back to the SIS.
If your merges are consistently triggering the threshold check, submit a support ticket so that Coursedog can evaluate raising the threshold.
Merge Dashboard
The Integration Dashboard provides a high-level overview on the status of specific merges, including errors in the integration between Coursedog and the SIS.
It is connected to the Merge Reports module, allowing you to View Report Details for merges that contain issues and expand the section containing errors.
For investigation and resolution of integration issues, use “Merge Reports” instead.
Merge Reports
Overview | Adding Filters | To Resolve Merge Errors
Overview
Merge Reports list all merge actions that have occurred between Coursedog and the SIS. This functionality is used by Admins and the Coursedog team to troubleshoot and validate merges.
Adding Filters
Overview
You can filter Merge Reports according to Merge Report ID, Merge Type, Execution Type, and Merge Status.
If the selected Merge Type is Sections or Relationships, two additional fields will appear: Term Code field followed by Entity ID.If the selected Merge Type is Courses (CM) or Programs, one additional field will appear: Entity ID.
Entity ID
Overview
Entity ID gives admins the ability to search for and troubleshoot specific records directly within the Merge Reports screen.
Finding the Entity ID
In most cases, you can find the Entity ID by exporting and viewing the related report from within the Scheduling Reports page.
You can also obtain the Entity ID by using the API for the entity.
USING REPORTS
You can find the Entity ID for Sections and Relationships by downloading the corresponding report available at Academic Scheduling > Reports > Export.
For the Section ID – Download the “Course Sections List” report and reference the “Section ID” column (as shown in the first screenshot below).
For the Relationship ID – Download the “Relationships List” report and reference the “Relationship Name” column (as shown in the second screenshot below).
USING THE API
For Courses (CM) and Programs, you will need to use the API to obtain the correct ID.
To access your school’s API for any given entity, you will need to know your School ID. This can be found at Admin > Settings > General Settings > “School Unique ID” (see first screenshot below).
For Staging Courses, the API can be found at https://staging.coursedog.com/api/v1/cm/<school ID>/courses
For Production Courses, the API can be found at https://app.coursedog.com/api/v1/cm/<school ID>/courses
For Staging Programs, the API can be found at https://staging.coursedog.com/api/v1/cm/<school ID>/programs
For Production Programs, the API can be found at ttps://app.coursedog.com/api/v1/cm/<school ID>/programs
In the response from the API, the _id field value is the Entity ID (see second screenshot below).
To Resolve Merge Errors
Restore Past Data
If a merge resulted in unwanted changes, you can restore the data back to what it was at the end of the previous merge.
This restores all Coursedog data for the entity type selected - including non-integrated fields.
For example, you had a successful nightly merge 123 that ran as desired. The next nightly merge 456 ran with a wrong configuration and wiped some of your data in Coursedog. You want to get your Coursedog data back to how it was after merge 123 ran. To do that, select the merge group that contains merge 123 and click Restore Data. This will restore your Coursedog data for the selected entities back to what it was right after the merge completed.
A merge group represents a set of nightly or realtime merges that ran together - for example, a nightly merge across all entities. You can find the merge group id of a merge on the merge report.
To Restore Data from a Past Merge
Step 1: In Merge Settings, make sure realtime merges are turned off. Otherwise, turn them off (temporarily) to avoid any changes from being discarded.
Step 2: In the Merge Reports tab, open the report of the merge you want to get back to (likely the last successful merge). Copy the Merge Group Id and, if relevant, note the Merge Type (if you only want to restore data for a specific type of entity).
Step 4: Click Restore Data. A modal will open where you can select which entities you’d like to restore. Make your selection, click Restore, and confirm.
Step 5: As soon as you start the Restore, you can navigate to the Activity Tab to track the status of the operation.
Step 6: Once the Restore is complete, you should run a manual merge for that entity to send the restored data to the SIS. Set the source of truth as Always Coursedog (otherwise the restored data will get overwritten by the SIS).
Step 7: If you disabled realtime merges in step 1, enable them back.
Merge Notifications
Admins should subscribe to notifications and manage their merge errors proactively.
During the onboarding phase, the Coursedog team will usually be subscribed as well.
You can learn more about setting up merge notifications here.
Integration Health Check
This can be used to determine the number of objects being merged and can also serve as a red flag, indicating failures; however, this is not heavily used as we normally recommend utilizing merge notifications and merge reports instead.
The check includes:
The integration endpoint for each type does not respond with any errors.
The data for each type passes our internal verifier.
There are no invalid ID references (e.g. courses with department IDs that are not present in the department data).
Any text fields with a value of “null.”
Any text fields that start with a space.
Any section with a meeting pattern that starts after it ends.
Any section with overlapping meeting patterns.
Rooms and buildings with empty display name.
Multiple terms with the same year/semester combination.
Merge Settings
Overview | Merge Types | Term-Specific Merge Settings
Overview
All integration merge settings are defined here:
Whether the integration is on or off.
Integration schedule, including whether real-time integration is ON.
How we resolve data conflicts with the SIS / Modify Source of Truth between Coursedog vs. SIS (it is recommended that you engage Coursedog Services/Support when making updates).
Term management (which terms are being integrated).
Custom field management.
“Merge Settings Overrides” allows you to specify different settings for the real-time merge versus what is defined for the nightly merge.
Configure and manage “Saved States” to sync to Phases in the scheduling cycle (if applicable/desired).
Adjust the "Real Time Integration Schedule." For example, if set to 60 minutes, the integration will be automatically executed every 60 minutes. If set to 0 then sections and relationships are posted to the SIS on save in the Coursedog Section Dashboard and relationship editor User Interface.
Clicking on "Merge Settings Overrides" allows you to specify different settings for the real-time merge than what is defined for the nightly merge. Your Coursedog data engineer and project manager will have configured this for you during setup of your integration, but if not and you want real-time integration enabled, please reach out to Coursedog support.
Merge Types
Merge types can be enabled or disabled for a school, which indicates whether the integration is “on” or “off” for that entity.
A sample configuration is shown below.
You can find a breakdown of common merge types, and the products they’re used for, here.
Term-Specific Merge Settings
The following data have term-specific merge settings: Courses, Sections, Relationships, and Course Attributes.
This means when turning on the integration for a new term in scheduling, the settings for each of these data elements must be adjusted to add in the new term.
Course attributes have term-specific settings because course attributes are used in scheduling to populate the "Section Attributes" select input and the attribute options can vary across terms.
Details for all Merge Settings can be found in the overview tab.
Integration Attribute Mappings
These are all the mappings for any data source where the SIS stores it as a code (i.e. LEC), but it is presented in Coursedog as a description (i.e. Lecture). The mappings for all users and roles are contained here, along with mappings for data elements that are not pragmatically retrieved via the integration. See here what will happen if you’re missing an attribute mapping.
If the mappings ever update globally, they can be updated in the Central instance and be pushed to each campus.
If campuses need customizations to their mappings, this data can be edited in each Campus-specific Admin Dashboard.
Integration Filters
These are used to exclude data from the SIS that we don't want in Coursedog.
Both the Integration Attribute Mappings module and Integration Filters module are typically configured during onboarding.
Learn more in Integration Data Filters.
Demand Analytics
This module is used to define/configure demand analytics settings in the Coursedog platform as well as manually push a refresh of data/calculations. Settings and Guidance is provided within the User Interface.
Catalog URLs
This is primarily used by the Coursedog Services team to help manage your Catalog URL lifecycle (i.e. the individual URLs required to support your current, past and future catalogs).
New Revision Behavior
Use this to select which Coursedog-owned fields to persist when a new course or program revision is created in your SIS.
Data Migrations
This is an internal, Coursedog-only tool that is used by Coursedog team members to support customers during implementations and post go-live.
The tool is used to copy data and settings from one environment to another. This includes many data types, including templates, forms, workflows, departments, roles, users, rules, terms, meeting patterns, and more.
Example uses include:
Cloning baselines environments to a new school’s staging environment.
Cloning a staging environment to production.
Cloning a production environment back to staging.
The first two uses listed above only apply to new customers undergoing implementation.
Once customers are live, only the third option – cloning a production environment back to staging – applies. Learn more about how that works.