Table of Contents
Overview
Accessing Forms
Adding Forms
Form Setup
Attaching Workflows to Forms
Assigning User Roles to Forms
Previewing Forms
Publishing Forms
Filter for Published and Unpublished Forms
Editing & Deprecating Forms
Archiving Forms
Related Articles
Overview
Coursedog’s configurable, digital form builder allows administrators to define what information must be collected in a valid proposal.
The most common proposals include New Course Forms, Edit Course Forms, and Edit Program Forms.
Forms consist of questions from the corresponding template (e.g. the course template for a course form) and custom questions.
The form is essentially what an end user will fill out when they complete the specified action, such as proposing edits to a course.
Custom questions on forms are assumed to be fields that only exist on the form. Any data captured in a form custom field that is not associated with the template will NOT be passed into the resulting object once a request associated with the form is approved.
For example, if you have created a “New Course Form” with the custom question “Why do you want to create a new course?”.
The data captured in the “Why do you want to create a new course” field will be captured in all requests when a user submits a request using the “New Course Form”. However, if the request is approved, the data from this question will not be part of the corresponding course that gets added to the curriculum inventory.
Accessing Forms
To access the Forms Dashboard, select “Forms” on the left navigation.
You will be taken to the Forms dashboard where you can see all of the existing forms or create new forms.
Adding Forms
PATH: Curriculum Management > Forms
Overview | Creating a Form from Scratch | Duplicating an Existing Form
Overview
There are two ways to add forms: manually (from scratch) or by duplicating existing forms.
You can get step-by-step guidance in-app to help you create a new form. To activate a guided walk-through, navigate to Curriculum > Forms > + Add Form. If the flow doesn’t automatically begin when you click “+ Add Form”, look for it in the “In-App Guides” widget on the right-hand side of your screen.
Creating a Form from Scratch
Step 1: Click “+Add Form”.
Step 2: Click “Create a New Form”.
Step 3:
Input a name, action, type, and workflow.
Name – This should be specific enough that end users are able to easily select the appropriate form. An example might be “New Course Form”.
Action – There are three options: New (e.g. New Course), Edit (e.g. Edit Course), and Delete (e.g. Delete Course).
Type – Dropdown options will be Course, Program, and any Document Types you’ve created.
Workflow – Since this is required, you will need to ensure you’ve already created the workflow you’d like to use for this form (you can edit the workflow at any time). Learn more about creating workflows here.
Step 4:
Click “Add”.
The form will automatically pre-populate with all of the fields from the course or program template (depending on the selected type).
Step 5:
Add additional questions/fields to reflect your need.
Note that once a request that uses this form is approved, these additional fields won’t appear on the course or program record in the frontend UI because they aren’t on the corresponding template. However, anyone reading course data via API can see that the field and the value are stored in the underlying JSON record.
See “Form Setup” below for additional guidance on form creation.
Duplicating an Existing Form
Step 1: Click “+Add Form”.
Step 2: Click “Copy an Existing Form”.
Step 3:
As outlined above, input a name, action, type, and workflow.
You will also need to select the form you wish to copy from the “Form to copy” dropdown.
Step 4:
Click “Add”.
The form will automatically pre-populate with all of the fields from the form you copied.
Step 5:
Add additional questions/fields to reflect your need. Just remember nothing you add here will not be included in the course or program record.
See “Form Setup” below for additional guidance on form creation.
Form Setup
Cards | Question Bank / Field Types | Field Values | Field Settings | Automatically Generated Cards
Cards
Forms are made up of cards. Cards hold specific data fields and questions. Some cards, such as Requirements, have extended functionality and cannot be customized.
To create a new card, click the “+” button on the top right of an existing card. This will allow you to add a card above the one you’re selecting.
You can re-order cards via the “Card Order” option located on each card. You can either:
Click the up or down arrow. OR
Manually input a specific order number (cards will move to the specified order after you input the number and click out of the “Card Order” box).
Question Bank / Field Types
Overview | Custom Fields | Course/Program Template Fields
Overview
The course template can have two types of fields: Custom Fields and Course/Program Template Fields.
To add a field, simply drag it from the Question Bank onto the template.
Custom Fields
Custom fields allow users to add fields necessary for internal processes. These fields, including “Owners Select”, do not have any extended functionality.
Learn about the difference between Text and Textarea fields here.
Our WYSIWYG field enables the user to input and format their content. Users can add tables, images, headings, hyperlinks, page links, and program links.
Files
OVERVIEW
If the “files” field is on your template/form, users will be able to upload files as part of their proposal.
We suggest keeping files under 5MB to prevent performance issues.
FILE PRIVACY
Users will be able to determine whether or not a file is public when they upload it. If the toggle is set to “yes”, the file is public. If the toggle is set to “no”, the file is private. We default all files to private UNLESS the user decides to make the file public.
If you are also a Catalog customer and a file is set to “private”, it will not be visible in the catalog. If a file is set to “public”, it will be visible in the catalog so long as the “files” field is visible on the Catalog page template.
An admin can also use field settings to limit which roles/users can see files during the review process (you do this by clicking the field on the template and changing visibility settings; see “Visible” below for details).
Single Course Select
This can be used as a Coursedog-only field to capture equivalent courses or as a field on program forms to indicate which course satisfies an upper division requirement for the program.
This does not indicate a bidirectional relationship.
Integration Note
To prevent a custom field from being wiped during a nightly merge, you will need to ensure it has been added as a Field-Specific Exception, with the Source of Truth set to “Always Coursedog”.
This is configured by an Admin at Admin Dashboard > Merge Settings > Type-Specific Settings > (Select Entity) > Field-Specific Exceptions.
Course/Program Template Fields
Course and Program Template fields contain specific fields in the SIS, contain fields that allow for extended functionality in other areas of the Curriculum product, and contain fields defined within the course template. This includes custom fields defined within the course and program template, even after the form is created.
Field Values
Overview | Question Title | Question Description | Question Extended Description
Overview
Each field has three values: Question Title, Question Description, and Question Extended Description.
Question Title
Question title is the question that will be displayed to the end user.
Question Description
Question description displays as help text to the end user. It will only appear if the end user hovers above the “?” symbol.
Question Extended Description
Enables the user to edit text in a WYSIWYG modal. This is useful for adjusting font size (using h1-h3 headers) and including tablets, hyperlinks, or extended formatted descriptions for end users to use when answering questions.
The below image captures the extended description; it appears to the right of the “purposes and goals” question.
Field Settings
Overview | Is Required | Placeholder | Allow Multiple Select | Editable
Visible | Configurable | Default Values | Min and Max Number of Characters
PDF Output | Actions | Disable Copying
Overview
Each field has its own settings. You can access these settings by simply selecting the field from within the form template.
You will see the Question Settings appear on the left side of the screen. From here you can edit specific settings.
Role-Based Access Control (RBAC) is available for individual fields for both the Course/Program template as well as all curriculum forms.
Some common settings are outlined below.
Is Required
Determines whether or not users will be allowed to leave this field empty.
Placeholder
This determines what will appear before a value is entered/selected.
Allow Multiple Select
This appears on “Select” custom fields.
Checking this box and creating options using "+ Option" will allow end users to select more than one option.
- Checking the “Allow Multiple Select” box is required if you wish to give end users the ability to see multiple values saved within a field.
- If you are working with a course or program where this is checked and multiple options have been selected – but then deselect “Allow multiple select” – only the first option will be displayed when viewing the field.
Editable
If “Editable” is checked and no roles are listed, all roles will be able to edit the field.
If “Editable” is checked and roles are listed, only those roles will be able to edit the field.
If “Editable” isn’t checked, no roles will be able to edit the field.
Only a “Super Admin” Can Edit This Field
TEMPLATE SETTING
FORM VIEW FOR A SUPER ADMIN
FORM VIEW FOR ANYONE OTHER THAN A SUPER ADMIN
Visible
This setting works in much the same way as “editable”:
If “Visible” is checked and no roles are listed, all roles will be able to see the field.
If “Visible” is checked and roles are listed, only those roles will be able to see the field.
If “Visible” isn’t checked, no roles will be able to edit the field.
Configurable
Overview
The “Configurable” setting is crucial to ensuring that no one removes or modifies needed fields, such as fields required for the integration.
This setting controls which users can access the left-hand navigation set of Question Settings. If a field does not have the “Configurable” box checked at all, that field is no longer configurable in any way to any user.
Users with the “Coursedog” role can check this box to allow other users to configure the field in case that box is unselected accidentally.
Alternatively, the box can be selected but with certain roles allowed to configure the field.
The Configurable setting on the Template persists to the Form. This means that the Configurable setting allows an admin to “lock” a field and ensure that it persists untouched onto Forms.
How to Set It
Keep the box checked to allow the field to be configured by all users.
Keep the box checked and multi-select applicable roles to determine which roles have configuration access granted for this field.
Uncheck the box to lock this field and prevent any uses from configuring it further.
Example Use Case
Field X is required for an integration to run successfully.
Keeping the “configurable” box unchecked for Field X will prevent other users from removing it from the template or modifying its settings.
Default Values
Default values can be set up for fields, either using custom default values (input by users) or from a source (dynamically fetched from another data source).
The department field can be dynamically defined as follows:
User Primary Department defaults the department field to the user’s primary department.
User Departments defaults the department field to all the user’s associated departments.
Min and Max Number of Characters
The minimum and maximum number of characters in a response to a form question can be specified in the field settings.
If a user attempts to answer the question under or above the character count thresholds, an error message will appear specifying the error (the user may have to click into the input box and out for the validation message to appear).
PDF Output
Each field has the below “PDF Visibility” settings that default to: ToC & Content.
That means the field will show up in the Table of Contents (ToC) and in the content of the PDF.
To hide content from the PDF, click “hidden”.
Note that if fields are visible to any user, they will appear in the PDF.
Actions
Overview | Actions for Pre-Built Select Field Options | Basing Actions on Workflows
Actions in Questions with Nested Fields
Overview
Actions generally work the same in both Curriculum Management and Academic Scheduling.
You can find a general overview of how Actions work – and how to set them up – here.
See below for Curriculum-specific actions functionality.
Actions for Pre-Built Select Field Options
OVERVIEW
Users can configure actions/logic (in pre-built select fields with a dedicated merge) to limit which downstream options users see based on other selected fields in the template.
For example, a user proposing a new undergraduate course can select “Undergraduate” for Career. They open the dropdown for Grading Basis, and only see grading bases that are valid for undergraduate courses as opposed to all possible grading bases. This limits possible instances of invalid data entry.
How to Do It
STEP 5a: Follow all of the steps outlined here for creating actions, but ensure you are configuring a “select” pre-built field and have selected “Update Field Config” for Step 5.
STEP 5b: Click “Set Config”.
STEP 5c:
Add or remove available select options for that field.
You can remove options by selecting the “x” next to it.
You can add more options by selecting them from the “Add More Options” dropdown.
If no options are appearing, close out of the modal; add them from within the field’s main Question Settings; and then return to the Actions configuration.
STEP 5d: Click “Close” to close the modal.
Basing Actions on Workflows
When creating request actions in curriculum forms, users can pull from data in the workflow to set specific actions.
The most common use case is to set a field as “required” on a certain workflow step.
In the below example, the user has configured the action as follows: If the workflow step name is “Step 1”, then make the field required.
TESTING ACTIONS FOR WORKFLOW STEPS
Preview the form against a specific workflow step so you can see how the form changes at different steps. In the below example, we are previewing the form in “Step 1”, which shows that the “Name” field is required due to the action.
Actions in Questions with Nested Fields
When you add an action to a question with nested fields, the action will work on every element in the collection if “Field Group” is set to “Form”.
If “Field Group” is set to “Record”, then the action will apply to every element individually.
If you wish to use “Parent Level Up by X” as the Field Group when creating actions associated with nested fields, the “is collection” box has to be checked. If not checked, related actions won’t work properly. Learn more about questions with nested fields here.
In situations where you need to compare fields next to each other in a collection, you should use the Record field group when creating your action.
Disable Copying
Users are able to pre-populate proposals based on data found in existing proposals or existing courses, programs, or document types.
There is a “Disable Copying” setting to define which fields are allowed to be copied via the pre-populate process when proposing a new course or program.
This can be found in the Course and Program template as well as all Curriculum forms.
Signature questions are hardcoded to never allow copying.
When you propose changes to an existing course or program, that proposal will automatically copy over all data regardless of this setting, since the proposal is to edit something that already exists. However, when editing the proposal itself, you can choose to “Copy from Proposal” to add additional data, at which point the “disable copying” setting will take effect.
Automatically Generated Cards
Different forms can include different prebuilt cards.
Attaching Workflows to Forms
When a form is submitted, it goes through an approval workflow to be approved. You can select which workflow from the form editor in the top right.
To learn how to build workflows, check out this article.
Assigning User Roles to Forms
There is a multi-select field labeled “allowed roles” at the top of each form.
This field can be used to restrict which user roles are allowed to submit a proposal using that form.
By default, all roles are selected, but a user can multi-select roles if they wish to restrict proposal submission using the form to just those roles.
This does not apply to form routing. For form routing, you can either allow all roles or, again, specify the roles as described here.
Previewing Forms
At any time while editing your form, you can select “Preview” in the upper right corner to interact with an example of what the form would look like.
Publishing Forms
At the top right of each form, there is a “published” toggle. This toggle controls whether or not a form appears when a user selects “propose changes” in the course or program inventory. The form will still appear to users if the form is used in form routing.
The “published” toggle should be used to control whether or not forms are visible to end users who are submitting proposals. When you do not wish for them to use a form to submit a proposal, you should turn the “published” toggle off.
When new forms are created, the toggle will default to “false.”
Filter for Published and Unpublished Forms
The user can filter for published and unpublished forms within the forms dashboard.
Editing & Deprecating Forms
If you edit a form, any in-flight proposals utilizing that form will automatically be updated to reflect the newest version of the form. This will affect what the workflow step participants see when navigating to a given proposal in the “Proposals” dashboard. It is recommended you create a new form versus editing (and archive the old form).
If users want to update a form and don’t want existing proposals to be impacted:
Duplicate the existing form.
Make adjustments to whatever fields are needed in the new version of the form.
Check/update workflow to ensure that logic jumps aren’t tied to the old version of the form.
Add new form to form routing.
Archiving Forms
Best practice is to archive forms (deleting the form will impact draft and in-flight proposals). To archive:
Rename the form to indicate that the form is inactive.
Remove that form from Form Routing.