Page History

...

The Workflows screen within the Admin Panel lets you build everything described above as well as allows you to edit existing workflows in the event that these need to change after they have been finalized.

...

A description of the items highlighted and numbered in the picture above:

1. Box # 1: The Record Type select to see Workflows for; in this image, we are looking at workflows for Grant Requests (i.e. Grants and Grant Applications).
2. Box # 2: The specific Theme (form) that we are reviewing/editing the workflow for. Every separate Theme can have its own unique workflow (or they can follow the same Workflow of another Theme).
3. Box # 3: Points to three different Statuses (every White Bar across the screen = a separate status). Each status displays its External Name (i.e. "LOI Draft" or "First External Review") followed by its Internal Name in parentheses (i.e. "draft" or "first_external_review"). Clicking on one of these bars gives a few options. See the section Status Options to see what those options are and how these statuses can be configured/edited.
4. Box # 4: Points to the various different Buttons that allow users to move a record from one status to another. Buttons are specific to a given status (hence why the buttons appear underneath Statuses; the status that the button is under is the status in which that button will be available for records of this Theme). Like with statuses, clicking on one of these buttons gives a few options to change/edit/configure these buttons. See the section Button Options to see what those options are and how these buttons can be configured.
5. Box # 5: Shows the "New State" button, which allows you to create a New Status bar. It is recommended to avoid creating new statuses unless they are absolutely necessary. A status created in one record type (i.e. Grant Requests) will be available for ALL THEMES found in that record type (though not every status has to be used for every theme). Having too many statuses makes things very complicated and makes maintenance much harder. If you DO need to create a new status. , see the the Status Options section for tips as to how to fill out the required fields.
6. Box # 6: Shows the "+" button that allows you to create a new Button underneath a particular status. The same best practices for statuses applies for Buttons (i.e. don't create unnecessary ones, avoid creating new ones unless absolutely necessary, keep number as low as possible for easier maintenance). If you DO need to create a new button, see the Button Options sections for tips as to how to fill out the required fields.

...

1. Box # 1: Shows the Button that you currently have selected. You can tell which Button is currently selected NOT ONLY based off of the name (match name of Button with "Button Name" from box # 2), BUT ALSO from the slim green line that appears to the LEFT of the button name.
2. Box # 2: Shows the configurable Button Name. This is the title of the button as it appears when an External or Internal User goes to move the record to another status. The Title of the Button should be closely related to the Status that the button moves the record to (see box # 5 to see which status the button will move the record to). In the image above, for example, the button moves the record from a status of "LOI Draft" (the "New" status when the record is just created and not yet submitted by the Grantee) to a status of "Eligibility Review" (the first review status for the WPP team). Since this button is effectively "Submitting" the record to the WPP for the first time, this button is titled "Submit."
3. Box # 3: Shows the "Suppress Validation" checkbox. Don't click on this. If selected, the system will not run any validation on the record when this button is "pressed" and will move the record to the new status without any controls. The WPP always wants to run validation when a button is selected such that records don't move statuses inappropriately (i.e. when not all of the Required Fields have been filled out).
4. Box # 4: Shows the "From States," i.e. the status from where this button will be available for selection. In general, it's recommended that each button should be available From just 1 status so that it's easier to update buttons/button names without changing how multiple buttons work (easier from maintenance perspective).
5. Box # 5: Shows the "To State" i.e. the status to which the button will move the record when this button is pressed provided no validation errors are present (e.g. Grantee did not fill out a required field, etc.). This is a Single Select field for obvious reason (i.e. one button can only move a record to 1 unique status).
6. Box # 6: Shows the "Allowed Roles" for a button. This multi-select fields allows you to configure which Program Roles are able to use this button. Best Practices Recommendation: Only users who should be using this button should have access to select this button. For example, since Employees should generally NOT be submitting applications on behalf of Grantees, we've only given access to the "Submit" button to Grantees for this Theme as they are the ones who should be submitting their applications.
7. Box # 7: Shows "Delete" allowing you to Delete this status Button. Generally, deleting a Button is safer than deleting a Status as buttons are unique for each Theme (as opposed to Statuses, which are consistent across each data type). However, it is import to ensure the main buttons are available (like "Submit") or else Grantees/other users will be unable to move records of that Theme to the desired status, breaking the workflow and requiring Employee (or Admin) intervention.