Table of Contents
Filter for Published and Unpublished Forms
Assigning User Roles to Forms
Editing & Deprecating Forms
Forms allow for 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. Coursedog provides a configurable, digital form builder that allows users to define what information must be collected within a form.
Forms consist of questions from either the corresponding template (i.e. the course template for a course form) and custom questions.
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.
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.
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.
By clicking on an existing form or selecting “+Add Form”, you will see that a form is simply a template of cards and fields that manifests into an interactive form when a user goes to complete the specified action, such as proposing edits to a course.
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.
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.
Forms are made up of cards. Cards hold specific data fields and questions. Some cards, such as Requisites, have extended functionality and cannot be customized.
To create a new card, click the “+” button on the top right of an existing card.
The course template can have two types of fields: Custom Fields and Course/Program Template Fields.
Custom fields allow users to add fields necessary for internal processes. These fields, including “Owners Select”, do not have any extended functionality.
Our WYSIWYG field enables the user to input and format their content. Users can add tables, images, headings, hyperlinks, page links, and program links.
If the “files” field is enabled, users will be able to upload files as part of their proposal.
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.
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.
Each field has three values: Question Title, Question Description, and Question Extended Description.
Question title is the question that will be displayed to the end user.
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 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.
To add a field, simply drag it from the Question Bank onto the template.
Currently all form changes are immediately reflected in active proposals (i.e. if fields are added they will be reflected in proposals in-flight).
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.
When “Editable” is disabled, the associated Role will be able to fill out the form or edit the field on the course/program template:
Field 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.
Field Settings - 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).
Field Settings - 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”.
Field Settings - Actions
For each question, a user can create a list of Actions comprised of conditional statements that can be used to update the value or configuration of another field.
Note, forms actions do NOT update and set field values without editing the course/program. A proposal or direct edit must occur for actions to trigger.
The below example shows an action that updates a field’s settings based on a specific condition.
Users are able to define actions that configure the value of a field to be the same value as another field. This can be done within actions by setting a “then” condition of “update the field’s value” to the question ID of the field you want to copy from.
Actions can be used to define what fields are selected and deselected in a select field. This action type can be accessed within actions > then > toggle field value.
Note that this option is only available if the field has the “allow multiple select” configuration enabled.
There are three toggle modes within “toggle field value.”
Toggle – Toggles which options are selected.
Add Only – Adds selected options.
Remove Only – Removes selected options.
There might be cases in which users want multiple actions to control the options selected in another field. In these cases, users should utilize the “add only” and “remove only” toggles to not override all selected options, which is what the “toggle” function would do.
Users are able to select, in the event of the action occurring, which select options should be impacted.
Field Settings - Disable Copying
Users are able to pre-populate proposals based on data found in existing proposals or existing courses, programs, or document types.
To define which fields are allowed to be copied via the pre-populate process, there is now a “Disable Copying” setting for each input.
This can be found in the Course and Program template as well as all Curriculum forms.
Signature questions are hardcoded to never allow copying.
Downstream Workflow Actions
When creating request actions in curriculum forms, users can now 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 now required due to the action. |
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 rows” 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.
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.
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.