Overview
A workflow is a named list of tasks to be accomplished for a given business process. Workflows are set up by a system administrator via the Workflow Templates page. Workflow tasks are displayed on the My Tasks page and on the Workflow and Tasks tab of any detail page that supports workflows—namely, one of the following pages:
Submission Details
Evaluation Details
Compliance/Enforcement Action Details
Project Details
Tasks within a workflow are assigned to specific workgroups and/or users.
Workflows are assigned to submissions (applications/requests or schedules), evaluations, and compliance actions. Each item can be assigned multiple workflows if desired.
Workflows can have a status of In Process, Complete, or Withdrawn.
Tasks within a workflow can have a status of Unstarted, In Process, Complete, or Withdrawn.
Automatically Created Workflows
Under certain circumstances, applications may have one or more workflows added to them automatically upon receipt into nVIRO. These default workflows for new applications are set up by a system administrator when configuring form behavior. An important caveat is that, in order for a default workflow to automatically be added to an imported application, the permit category for that workflow (configured in the "Permit Category to Create" field on the Edit Workflow Template page) must not have any associated permit types. This is because, for permit categories that include one or more permit types, it's not possible to know in advance which permit type should be added to the application upon import; rather, the assignment of a particular permit type is a manual operation that the application processor needs to perform after importing the application.
Other types of items, such as evaluations and schedules, may be configured to have default workflows added to them when the items themselves are created.
Special Behavior of Application Workflows
In the case of workflows which apply to applications, each workflow is configured to affect (or not affect) permits in a designated way. For example, a workflow template for processing an application for a new permit would be configured to create a new draft permit.
| Info |
|---|
Assigning a workflow to an application is a fundamental and critical action within the system, because it is at this point that a new permit record (or a permit revision or renewal record) is created. |
For application workflows, a workflow can be configured for one of the following permit behaviors:
Does not create or change a permit
Creates a new v1.0 permit
Creates a revision to an existing permit (e.g., v1.0 to v1.1)
Creates a new version of an existing permit (e.g., v1.0 to v2.0)
Unlocks an existing permit version for editing
Workflow affects current permit version (this option allows the linked permit to be edited; useful for permit terminations)
Permit Version/Revision Creation Behavior
When a workflow creates a new permit version or revision, information on the new permit version is copied forward from the existing permit version.
Contacts on the new permit version are combined from both the submission and the existing permit. If a contact exists on both the submission and existing permit version that shares the same contact name, the contact information from the submission will be carried forward to the new permit version. All other contacts from both the submission and the existing permit are carried forward onto the new permit version.
In the event that there is no contact with a Permittee role on the existing permit version or the submission, the submission’s applicant contact will become the permittee on the new permit version.
The diagram below illustrates an example of contact combination behavior when a new permit version is created.
