When a user submits a change to your catalog, it goes through the designated workflow.
Workflows function the same way in all products, with a couple exceptions. In Catalog, those exceptions include the ability to add department approvals as a dynamic step as well as the ability to base logic jumps off of catalog-specific content.
To learn how to build a standard workflow, see this article.
Workflow Notifications
All workflows give you the ability to define default email templates as well as the ability to further customize emails at both the workflow as well as the step level.
As with other dynamic steps, routing to multiple owners can be configured to occur in parallel or sequentially.
In instances of sequential review, if one owner rejects or edits the request, others will have to re-approve the updated request.
We don’t have the ability to define a number of votes for sequential steps because if one substep doesn’t get approved, then it shouldn’t go on to the next person, even if they’re all page owners.
If you wish to define a percentage of votes required for approval/rejection of a request with multiple page owners, you will want to select “parallel” as the step type.
Most workflows give you the ability to define “workflow privileges” that indicate what a user can do (e.g. Can vote, can comment, can suspend, etc.) when a workflow reaches them.
Things work a bit differently for Page Owners:
If the Page Owner is an individual, you cannot define workflow permissions. By default, Page Owners will have the following permission setup:
Can Vote (Approve/Reject)
Can Comment
Can Suspend
Can Route Back
“Can/Cannot Edit Request” permission is determined by RBAC set up at Catalog > Settings > Roles.
Can/Cannot Edit Workflow permission is determined by RBAC set up at Catalog > Settings > Roles.
Cannot Force Approve
Is Not Required to Comment Unless Routing Back
If the Page Owner is a committee, an Admin can define workflow permissions for individual committee members at Catalog > Settings > Committees > (Select Committee).
Substeps
If you see a reference to “substep” configuration when viewing a request, note that this terminology is being removed from the UI for steps tied to Catalog page owners, as there aren’t any substep configurations for Catalog page owners.
If a single page has multiple owners, then the review by each owner is a “substep”. What this means for your workflow is determined by whether it’s set to “parallel” or “sequential” review, as outlined above.
Logic Jumps in Catalog Workflows
Overview
Every workflow step can have a series of associated logic jumps – these are conditions that can be used to dynamically change the path of a request. For example, if your institution has both a graduate and an undergraduate catalog, you can use the same workflow for both but use a logic jump to determine where the pages go for review.
You can learn more about logic jumps in general here.
Catalog-Specific Fields
Overview
You can build your logic jump off of Catalog-specific fields, including Content, Page Name, and Catalog Page URL.
Content
e.g. If a catalog page contains X details, then go to Y.
Page Name
e.g. If a catalog page name equals X, then go to Y.
Catalog Page URL
e.g. If a page URL is X, then go to Y.
This looks for the unique Coursedog page URL, not the slug you have set up in the navigation.
For this to work, you would set the URL to reflect what appears in the address bar in the pages builder.
Assigning a Workflow to Change Requests
If you create multiple workflows, you will want to determine which one is assigned to catalog change requests.
A default workflow must be assigned (at Catalog > Settings > Requests) even if there is only one workflow configured.
You can configure your workflow(s) to meet your institution’s needs; even a workflow with the same objective can look very different depending on the school.
Below are two different approaches to a “Catalog Change Request” workflow, for example.
To zoom in for a better view, you can download the PDF(s) attached at the bottom of this article.
