Please note: A PDF version of this guide is available for download at the bottom of the article.

This manual takes users through the use of the Workflow Designer tool located in the System Administration section of iRIS™. Workflow Designer enables users to create workflow paths for forms defined in their system. Every submission form in iRIS™ must have an associated workflow in order to be successfully submitted to a review board. These workflow paths should mirror the real-world route a form takes to a review board in your institution.

Navigate to the Workflow Designer via the link System Administration > Workflow Designer menu item as shown below.

System Workflow Designer Templates

Navigate to the iRIS™ Workflow Designer via the System Administration > Workflow Designer link. This opens the List of all Templates page.

This page lists all workflow templates that are defined in iRIS™ in a template table, shown in the screenshot above. The columns of this template table are described as follows:

        Remove – Click this icon to delete the workflow template from the system.

Edit Workflow Graph – Click this icon to edit the current workflow. If the workflow has already been published, the only editing that can be done is defining the rules of a relation. To edit the entire workflow, select the Create New Version button.

View History – This folder expands to display each previous version of the workflow template in a read-only format.

Template Name – Identifies the name of the template.

Template Type – Identifies the submission type for which this workflow is defined.

Template Version – Indicates the number of times the workflow has been published.

Template Published – Indicates whether or not the template is published. If it displays “Yes”, the template is published and is being actively used by the submissions of this type. If it displays “No”, the template is not published. If this is the first version and it is not published, the submission type does not have an associated workflow.

Last Modified By – Displays the last user to modify the workflow.

Last Date Modified – Displays the date on which the workflow was last modified.

The Concept of Templates

Workflows in iRIS™ are graph-like structures that determine the path that a submission form takes as it travels through the system. Each form in iRIS™ may have its own workflow, and each of these workflows are entirely configurable.

A workflow’s template is a visual representation of the workflow’s structure and enables users to edit the contents of the workflow. An example of a template is shown below.

Templates are comprised of three basic components: levels, nodes, and relations. These items will be discussed in detail later in this document. Additionally, every template contains a green “Start” and a red “End” block signaling the start and end points of the workflow.

A submission travels (starting at Level 1) along each level of the graph until it reaches the end point of the workflow or when some criteria is not met.

After the workflow template has been created and defined it must be published in order for the submission form to use the workflow. Submitting a form that is associated to an unpublished workflow will result in that form remaining stationary in the system. However, if a previous version of a form’s workflow was published, the form will route according to the most recently published version of the workflow.

Published templates are locked to all changes except for rule definitions. To edit a published template further, a new version of the template must be created.

Add a Template

Navigate to System Administration > Workflow Designer to open the List of all Templates page shown below.

Click the Add a New Template button to create a new workflow template. The following popup window will open.

Here the user will select the type of workflow template they wish to create.

Associate Form Workflow / Shared EDC Workflow – Links the workflow to a submission form. Selecting this option will display a list of submission forms in iRIS™ that do not have any workflow associations. Only these forms may be linked to the new template as iRIS™ limits the number of associated workflows to one per submission form.

Sub Workflow – Sub-workflows differ from standard form workflows only in that they are not linked to any specific form. Instead, sub-workflows function similar to list configurations. A library of sub-workflows is created for different scenarios, and then various action items in iRIS™—such as review processes—can be associated to a specific one. This is useful for use cases when the system administrator may want an extra layer of control over the behavior of a submission form.

As an example, consider an institution that wishes to require further processing steps only for submissions that are assigned a review process of “Expedited” in a certain board. Perhaps all “Expedited” submissions need to be routed to another board before the processing in the original board can continue. In this case, a sub-workflow can be created that contains the nodes needed to route the submission. The workflow can then be linked to the “Expedited” review process through that review board’s Review Board Administration List Maintenance page, as shown below.

Once a workflow type has been selected and the Save Associations button is clicked, the Template Definition page will open.

From here, various workflow components such as nodes and relations can be added to the template to obtain the desired submission form routing using the editing toolbar provided at the top of the Template Definition page.

After the template has been successfully configured, it must be published in order for submission forms to use it. Publish the template by clicking the Publish/Freeze the Template button on the Template Definition page. The published template will be locked to all changes except for rule definitions. Once published, the associated submission form may begin using the workflow.

The added template record will populate in the template table on the List of all Templates page.

Edit a Template

Navigate to System Administration > Workflow Designer to open the List of all Templates page shown below.

Click the icon in the Edit Workflow Graph column to edit an applicable workflow template. The Template Definition page for the selected template opens, shown below.

Edit Unpublished Templates

If the template to be edited has not yet been published, various workflow components such as nodes and relations can be added to the template to obtain the desired submission form routing using the editing toolbar provided at the top of the Template Definition page.

The configured template can then be published by clicking the Publish/Freeze the Template button on the upper-right corner of the Template Definition page. The published template will be locked to all changes except for rule definitions. Once the workflow template is published, it becomes available for use with the associated submission form(s).

Edit Published Templates

If the template to be edited has been published, the template will be locked against all edits except for changes in the rule definitions. An example of a published template is shown below.

If changes other than rule definitions are desired, a new version of the template must be created by clicking the Create New Version button. This will refresh the Template Definition page to show an unpublished version of the workflow template. This template has a full editing tool bar as well as a version number incremented by 1, as shown below.

From here, various workflow components such as nodes and relations can be added to the template to obtain the desired submission form routing.

After the template has been successfully configured, it must be published in order for submission forms to use it. Publish the edited template by clicking the Publish/Freeze the Template button on the Template Definition page. The published template will be locked to all changes except for rule definitions. Once the workflow template is published, it becomes available for use with the associated submission form(s).

The edited template record will be updated on the template table on the List of all Templates page.

Remove a Template

Navigate to System Administration > Workflow Designer to open the List of all Templates page shown below.

To delete a workflow from the system, click the icon in the Remove column next to the appropriate workflow, as shown in the screenshot above. This will open the following confirmation window.

Click CANCEL to cancel the deletion and close the confirmation window.

Click CONFIRM to confirm the deletion and close the confirmation window. The selected template record will be removed from the List of all Templates page.

Note: Do not delete a workflow unless the associated submission form will also be deleted. If there are studies/projects associated to the deleted form and workflow, data loss may occur.

Template Configuration

In this section, the process for configuring workflows in iRIS™ is discussed.

Workflow templates are comprised of three basic template components: levels, nodes, and relations. Each of these components is described in the following sections.

Levels

Workflow levels define the organizational structure of a workflow template. These levels contain all of the nodes and relations of that particular workflow. A submission travels from level to level, starting at level 1, to the end of the workflow or until some criteria is not met. In this way, each level represents a different step in that submission form’s routing process.

In a typical submission form workflow, the first levels often contain action nodes used to initially route the submission and trigger certain events. Following the action nodes are often decisions, which determine the path the submission takes based on a pre-defined set of rules. Lastly, the decision nodes are followed by review board queues, which store the submission until it is processed by the review board. Note that this is a generalization mentioned for educational purposes and may not apply to your institution’s specific needs.

Add a Level

Open a workflow template by navigating to System Administration > Workflow Designer > [Edit a workflow graph]. This link will open the workflow’s Template Definition page, shown below.

All newly created workflow templates begin with one level: Level 1.

To add an additional level, click the Add Level icon in the template tool bar.

Doing so will open the following popup window, enabling the workflow creator to select the location that the new level will be placed.

Use the Insert Level before dropdown menu to select the level that the newly created level should precede. For example, if “End” is selected in the above window and Save is clicked, the new level will be inserted into the workflow template directly preceding the “End” block, as shown below.

Note: When a new level is placed before one or more existing levels, the level numbering will automatically update to keep a consistently increasing numbering system. The level content, however, will remain unchanged. For example, if a third level is added to the template above between Level 1 and Level 2, the new level will be renamed Level 2 and the previous Level 2 template will be renamed to Level 3. However, none of the level’s contents will be affected.

Remove a Level

Open a workflow template by navigating to System Administration > Workflow Designer > [Edit a workflow graph]. This link will open the workflow’s Template Definition page, shown below.

To remove an existing level from the workflow template, click the Remove Level icon in the template tool bar.

The following popup window will open.

Use the Level Number dropdown menu to select the level that is to be removed and then click the Save button.

Nodes

Nodes control what happens to a submission within each workflow level. There are three types of nodes in iRIS™: action nodes, queue nodes, and decision nodes.

Action Nodes

Action nodes indicate an action that iRIS™ will perform on a submission when it reaches this node in the workflow. Any number of actions can be defined for a particular workflow level, but not all of these actions need be performed. Which action nodes are executed is dependent on the configuration of the template and the specific submission.

Add an Action Node

Open a workflow template by navigating to System Administration > Workflow Designer > [Edit a workflow graph]. This link will open the workflow’s Template Definition page, shown below.

To add an action, select a level and then select the Add Action icon located in the workflow toolbar, as shown below.

This will open the following popup window.

This Define Action window includes two fields.

Level Number – Indicates the level to which this action will be added.

Action Type – A predefined list of action types. These types are hard-coded into iRIS™ and cannot be configured.

The action node types available in iRIS™ are discussed in the sections below.

Action Passthrough

There are two different types of Action Passthrough nodes:

Action Pass-through (Node is Displayed) – Used as a placeholder step, no action is taken on the submission when it passes through this step.

Action Pass-through (Node is not displayed) - Used as a placeholder step, no action is taken on the submission when it passes through this step. This is used to help organize more complex workflow diagrams.

Key Personnel Education Validation & Study Association

This action node verifies that the training status of personnel on a study is active and valid (provided their role on the study is set to be included in the training check).

When a submission reaches this step, iRIS™ will check the rules defined for the selected training groups and compare them against the users listed as personnel on the study to ensure that their training is in good standing.

Note: Regardless of the CITI Interface or any other automated training import process (i.e. the user training upload), rules must be defined for each training group(s) in order for the Key Personnel Education Validation & Study Association workflow action node to function properly.

Selecting this action node results in the display of two additional components: a Stop the Submission from proceeding to the Review Board yes/no selection field, and a list of the training groups set up via System Administration > List Configuration and Maintenance > Define Training Groups.

When Stop the Submission from proceeding = “No”:

Selecting “No” for the yes/no field allows the form associated with this workflow template to continue through the workflow when users are attempting to submit, regardless of the training status of the KSP on the form’s specific study.

If set to “No” and one or more users do not possess the required training, a warning will be displayed within the Workflow – Submission Tracking that the education validation has failed. This validation fails if the individual has no training listed, the training listed is expired, or their User Training status is set to “Inactive”. However, if the user(s) failing the validation have an activated “Override Flag”, the system will overlook any training deficiencies. This override flag can be configured for each user individually via the user training area.

When Stop the Submission from proceeding = “Yes”:

Selecting “Yes” for the Stop the Submission from proceeding to the Review Board field will freeze the submission form at that step of the workflow, at which point all users will need to have current up to date training for the study in order for the submission to be completed. Within the Workflow – Submission Tracking, a warning will display.

To complete the configuration of this action node, check the boxes next to the training groups that are to be validated.

The group(s) checked here will be the only group(s) against which the system will validate the personnel’s training records. Be sure to Save the action setup.

Note: System Administrators should also verify that each training group used in the Key Personnel Training Validation & Study Association workflow action node has been manually associated with each review board that will receive submissions via the workflow designer tool.

Key Personnel Education Validation & Study Association Using Rules

This action node will verify the user training of each personnel on a study (provided their role on the study is set to be included in the training check).

When a submission reaches this step in the workflow, iRIS™ will compare rules set up in System Administration > List Configuration and Maintenance > Define Training Group Rules against the study personnel’s training records to verify that their training is up to date for the study being submitted.

This differs from the previous node in that no specific training groups must be defined. Instead, the node itself deduces the training groups to validate against by analyzing components of the submission, such as study application data values.

This workflow step functions in the same way as the previously described node for stopping the submission in the workflow or allowing it to proceed with a warning if the validation fails.

Key Personnel IACUC Species Vaccination Validation 

This action node verifies the vaccination status of each species and personnel added to an IACUC study. A new Yes/No selection field will be displayed after selecting this action type.  

Note: This item is available for use only with the IACUC module.  

The list of vaccinations in iRIS™ is configurable via IACUC Assistant > Review Board Administration > List Maintenance Setup > Vaccination Configuration List.

This workflow step functions in the same way as the two prior steps for stopping the submission in the workflow or allowing it to proceed with a warning to the study if the validation fails.

Send E-mail with attached Submission Forms 

This node sends an e-mail with the submission form and its components attached to selected recipients. After selecting this action type, a template will be displayed enabling the user to configure the email. The e-mail subject and at least one recipient are required. Additional recipients can also be designated – this link is reserved for those recipients that do not have a user account in iRIS™.

Send E-mail with Merge Code

This node will send an e-mail containing any inserted merge codes. The window populates with the same components as the screen above, except that in this case the email will not contain the attached submission form.

After clicking the Insert Merge Code button, a new window will appear that lists all available merge codes.

Select a merge code and click OK. The code will then appear in the text editor.

Send E-mail by Role with Merge Code

This action functions the same as the previous node, except that here the e-mail messages are only sent to users with specific roles. A Role field is added to the window. Click this link to specify which roles will receive the message.  

Note: This is an email only – no attachments.

Send E-mail with Selected Components 

This action node will trigger an e-mail to send when a submission is completed by the review board. At this point, any components selected by the review board during submission processing will be attached to the message. 

Note: Proper use of this workflow action node will require configuration at the Review Board level. There are specific board properties that must be enabled in order for the bundle feature to work from both the Review Board and the workflow areas. Please see the applicable review board’s Properties manual for more information.

Review Board – RB Fee Validation

This action node is used to validate that the Principal Investigator’s fees are not outstanding. The system will check financial information for the Principal Investigator of the project. If the Principal Investigator has an outstanding fee then the submission will be automatically retracted.

Review Board Committee – Auto Assignment 

This action node will pre-select a Review Board Committee for the submission. Selecting this node type will display two more fields, enabling the System Administrator to select the desired Review Board and Committee.

Note: The committee list will not display until the Review Board is selected. The committee list will be blank if the selected Review Board does not contain any committees. In this case, the submission will be assigned to the Review Board itself. You must also ensure that the Review Board is set up in Committee mode, which separates submissions into committees as opposed to compiling them into one Review Board submission queue.

Review Board – Auto Assignment 

When this option is selected, a list of Review Boards available in iRIS™ will populate in a drop-down list. The System Administrator can select the board to which the submission will be automatically assigned.  

Review Board Committee – Auto Complete submission 

This action node is used to close out a submission from the review board committee level.

Typically, a submission will go to a board queue and will be processed through that board before being completed. This action node bypasses the need for a submission to go through a board in order to reach the completed state. An example of when this step would be necessary is for a submission that has been processed in a Review Board queue and can either be completed based on a decision or needs to go on to another review board or action in the workflow. If the decision causes the submission to be completed, this step can be incorporated into the workflow.

Review Board - Review Board Committee of Record for study

This action node sends the submission to the study’s committee of record. The node should typically be placed in Level 1. Level 2 would be a decision and Level 3 would be the review board queues.

Note that this node does not apply to Initial Review Forms.

Review Board - Auto Assign IRB Number 

This action node automatically assigns an IRB Number to the study.

Note: IRB Numbering must be configured in the IRB Review Board for this node to function.

Review Board - Auto Assign IACUC Number 

This action node automatically assigns an IACUC Number to the study.

Note: IACUC Numbering must be configured in the IACUC Review Board for this node to function.

Review Board - Auto Assign IBC Number 

This action node automatically assigns an IBC Number to the study.

Note: IBC Numbering must be configured in the IBC Review Board for this node to function.

Review Board - Auto Assign SRB Number 

This action node automatically assigns an SRB Number to the study.

Note: SRB Numbering must be configured in the SRB Review Board for this node to function.

Review Board – Auto Assign Responsible Analyst

This node auto-assigns an Analyst to a submission.

When this node is selected, the Select the Review Board, Select the Review Board Committee, and Select the Assigned Analyst are displayed, allowing the user to configure the auto-assigned Analyst.

Workflow Routing wait for parallel submissions

This action will hold a submission based on the definition of additional parallel submissions in the workflow. An example of this behavior is when a submission is sent to multiple Review Boards and needs to be reviewed by each one simultaneously. The submissions that reach this action node will wait for the processing to be completed at all review boards that were defined at the previous levels in the workflow before proceeding to the next node.

Lock Submission 

This action provides the ability to route a submission that is not locked, which would allow the form to be edited and modified. The user can specify where in the workflow process the submission becomes locked and read-only. This behavior is controlled with special actions such as “Lock Submission”.

Workflow Completed 

This action allows you to define a completed status for a submission that the workflow process would not know when the submission is completed. A workflow action of Workflow Complete enables the closure of submissions and allows the submission to move from “in process” to “complete”.

Change Study Status 

This action can automatically update the study status to that selected here. This action node can be utilized in several workflow levels to allow you to change the study status numerous times through the progression of a submission in the workflow.

Change Project Status

This action has the ability to automatically update the project status to that selected here. This action node can be utilized in several workflow levels to allow you to change the project status numerous times through the progression of a submission in the workflow.

Note: This functionality is available for use in iRIS™ e-Proposal & iRIS™ R&D module(s) only.

Personnel Review & Signoff from Select User Data Value 

This action node provides the ability to route review submissions to a specified iRIS™ user.  

Wait for all Signatures to be Approved

This action holds the submission until all signatures are approved. These additional signatures are typically defined at the review board level.

Wait for all Signatures to be Completed 

This action holds the submission until all signatures are completed (whether they are denied or approved). These additional signatures are typically defined at the review board level.

Cancel all outstanding Signatures

This action cancels all outstanding signatures. These outstanding signatures are typically defined at the review board level.

Denial Action for Workflow Assigned Signoffs

This action must be used in conjunction with the Feasibility feature of iRIS™.  

Send Study Personnel COI Questionnaire 

This action will send a COI Questionnaire to study personnel (for those Study Roles configured with the “COI Required” flag to “Yes”). This is a COI workflow action that would be used in submission forms such as the Initial Review or Continuing Review.

Set Covered Person “Yes” if COI required in Role

This action node updates the COI covered person status of project/study personnel based on their role. If any users on the project/study hold a role with “COI Check Required = Yes”, this workflow node will convert those users into “Covered Person = Yes” and set their Annual COI Due date to be 15 days from that day. If a user already is set to be a “Covered Person = Yes”, then this workflow will not change anything for those users.

Note: This node will execute two checks: 1) Are these persons on this proposal listed with a COI Required Role? If “Yes”, it will proceed with the second check. 2) Are these persons named a 'Covered Person'? If “No”, this node will switch the person's 'Covered Person' status from “No” to “Yes”. This will then generate an Annual expiration set for the following day. If “Yes”, no changes will occur.

Copy Reviewer between boards for the submission 

This action node enables a reviewer to conduct their review of a submission across multiple review boards. If a board member starts a review in one review board and the submission must be passed on to the next review board prior to having the review completed, this step can be used to copy the incomplete review over to the next board. The board member can then resume the review where it was left off.

Note: When using this step, the board member must have a role on both review boards and the reviewer checklist must be the same for both review boards.

Review Board selection by meeting Submission Due By

This action node is meant for review boards that assign submissions based on upcoming meeting dates. When using this action, the system will check the selected review boards and their meeting dates.

Whichever review board (from the review boards which have been selected, as seen in the screenshot above) has the next upcoming meeting and the Submission Due By date has not yet passed will receive the submission. If there is no Submission Due By date defined for the review board’s next upcoming meeting, the system will only look at the Meeting Date. For example, if today’s date were 6/10/19, the submission would be sent to committee one, which has a meeting date of 6/14/19 but no Submission Due By date.

Choose the item from Action Type and select the review boards defined in the system from the drop-down list.

The screenshot below shows how this item must be set up in order to work properly. The first level will contain the Review Board selection by meeting Submission Due By node, the second level will be a decision, and the third level will contain the boards that the submission could be assigned to.

The rules going from Level 2 to the boards in Level 3 should be set up as shown in the screenshot below. What to Validate will be “Selected board from Action” and the Data Value will be the review board the submission would go to.

Review Board – Study IRB of record

This action is used for submissions other than the Initial Review when you have multiple review boards that review the submission. This action is typically placed in Level 1 and checks the study for the IRB of record. Level 2 would be a decision and Level 3 would be the review board queues.

The rules going from Level 2 to the boards in Level 3 should be set up as shown in the screenshot below. What to Validate will be “Selected board from Action” and the Data Value will be the review board to which the submission would go.

Select the Save button after selecting the desired action type.  

Queue Nodes

Queue nodes are containers that hold submissions until they are manually processed by an iRIS™ user. These nodes are especially useful when more than one review board needs to review a particular submission.

Add a Queue Node

Open a workflow template by navigating to System Administration > Workflow Designer > [Edit a workflow graph]. This link will open the workflow’s Template Definition page shown below.

To add a queue, select the appropriate level and click the Add Queue icon.

The following popup window will display.

This Define Queue window includes two fields.

Level Number – Indicates the level to which this queue node will be added.

Queue Type – A predefined list of queue types. These types are hard-coded into iRIS™ and cannot be configured.

The five queue types available in iRIS™ are described below.

Review Board Submission Queue

This queue node places the submission form in the selected review board’s queue until the board completes the submission.

A Review Board Submission Queue dropdown menu is displayed to allow selection of the review board.

Review Board Committee Queue

Note: This queue node should only be used if the review board property rb.use_submission_by_committee is set to “Yes”. Please see the applicable module’s Review Board Administration manual for details.

This queue node places the submission form in the selected review board committee’s queue until the committee completes the submission.

This node is typically used only for the Initial Review Submission form workflow.

When selected, a dropdown menu of committees (listed under the applicable Review Board) will be displayed.

Note: The processing type of each review board is a configurable review board property; the processing type of each review board must match the selected review board type used in the workflow. For example, if committee processing is selected in the workflow, the associated review board/committee must have processing submissions by committee already enabled. For additional information please see the manuals regarding the iRIS™ Review Board modules that your institution has purchased.

Designated Personnel 

This queue allows the workflow creator to specify a user to review and signoff on the submission.

When the workflow reaches this node, the selected user will receive a task on their homepage that will enable review of the submission and its components. The user can then complete their review and apply their electronic signature. After the electronic signature is applied, the submission will continue through the workflow.

Note: This queue type should only be used for iRIS™ users who already have an account; it is NOT to be used for any outside collaborators that do not have access to the iRIS™ interface.

Study Personnel by Role

This queue will send the submission to all personnel who hold a certain role in iRIS™.

When this node is selected, a dropdown list will appear that enables selection of the desired role. Once the workflow reaches this step, any user on the study with this particular role will receive a task on their homepage that will enable review of the submission and its components. The user can then complete their review and apply their electronic signature. After the electronic signature is applied, the submission will continue through the workflow.

System Role

This queue enables users with a particular System Role to be included in the signoff of a submission, as long as that System Role has ‘Use for Routing in Workflow’ set to “Yes”.

If multiple users on the study hold the selected system role, iRIS™ will send the signoff task to each user with that role.

For example, the Investigator on a study has been given the System Level Role ‘Routing Role’ in their user account. When a submission form is submitted against their study, it sends signoff tasks to all Routing Role users. The user received a task on their homepage, but if other users have been assigned with this role, they will all receive this task as well. However, only one user is required to sign off. As soon as a user opens the task and completes the signoff, the other tasks will cancel, and the form will continue through the workflow.

Decision Nodes

Decision nodes represent decisions in the workflow. iRIS™ will determine where the submission will move next based on the rule(s) defined. Usually in this case there are two or more workflow items (action/queue/decision nodes) in the next level that the system must choose between.

Note: It is highly recommended that decisions be used for items that are required and will never be undefined. DO NOT attempt to use decision nodes for values that may be unavailable. For example, values from sections of forms that may not be visible due to branching logic, as well as values that may not exist at the time of the submission (i.e. Review Board) should not be used in decision nodes.

Add a Decision Node

Open a workflow template by navigating to System Administration > Workflow Designer > [Edit a workflow graph]. This link will open the workflow’s Template Definition page shown below.

To add a decision, select the level to which the decision will be added and click the Add Decision icon.

This will open the following popup window.

This Define Decision window includes two fields.

Level Number – Indicates the level to which this decision node will be added.

Decision Name – A user-defined name of the decision node. The purpose of this name is purely for organization and convenience and does not have any effect on the logic of the decision node. This field is required.

Once added to the workflow, logic may be applied to the decision via relations.

Edit Item & Remove Item

Open a workflow template by navigating to System Administration > Workflow Designer > [Edit a workflow graph]. This link will open the workflow’s Template Definition page shown below.

To edit or remove an action, queue, or a decision node, select the item then click one of the buttons shown below.

If editing, a page similar to the item’s add window will be displayed.

When an item is removed, all the relations connected to that particular item are also removed.

Relations

A relation is a connection between two nodes in the workflow. There are two different kinds of relations: a generic relation that simply shows the route of the workflow (black arrow), and a rule relation between a decision node and another item (red or green arrow). The two relations shown in the screen below are both generic relations.

Add & Remove a Relation

Open a workflow template by navigating to System Administration > Workflow Designer > [Edit a workflow graph]. This link will open the workflow’s Template Definition page shown below.

To add a relation, click the Add Relation icon in the template toolbar.

The following popup window opens.

Here the user will specify the level and item from which the relation will start. This is applicable when there is more than one item on a particular level. The order of the items on a level are in order from top to bottom, so if there are three items in a level, the topmost item is number 1, the middle item is number 2, and the bottom item is number 3.

Next the user must specify the level at which the relation will end. Typically, this is set to the next highest level. In the screenshot above, the relation extends from Level 2 to Level 3.

After configuring the placement of the relation, click the Save button to add it to the workflow.

When the relation is added, it appears as an arrow connecting the two chosen workflow items.

However, if the relation is created between a decision and another item, a red arrow will display between the two.

The arrow is red to indicate that there have been no rules defined for this relation. After a rule is defined, the arrow will become green.

To remove a relation, click on the relation then click the Remove Relation button.

Define a Rule

Open a workflow template by navigating to System Administration > Workflow Designer > [Edit a workflow graph]. This link will open the workflow’s Template Definition page shown below.

Rules can be configured for any relation stemming from a decision node. These rules comprise the logic of the decision node.

Note: Rules cannot be defined for standard (black arrow) relations.

To define a rule, first select a relation on the workflow graph by finding an applicable red or green arrow and clicking to select it.

Once a decision’s relation is selected, click the Define Rule icon in the template toolbar, as shown in the screenshot below.

This will open a Define Branch popup window similar to that shown below.

Here, one or more rules for the selected relation can be built. If the rule evaluates to “true”, then the submission will follow the route of the relation in question. If the rule evaluates to “false”, that submission will not travel along the relation.

The columns in the provided table are described as follows:

[select] – The checkbox column on the left-most side of the table is used to remove rules from the table. Select a desired rule’s checkbox and then click the Remove button to delete the rule from the relation.

Order – If there are two or more validations in the rule, their order is configurable based on the value of their Order column.

What to Validate – This drop-down list contains the data that the system will use to validate the rule.

Data Value – This column will populate differently depending on the item that is chosen from the What to Validate drop-down list.

Comparator – The comparator used to evaluate the rule validation.

Join by, if any – This drop down contains three values: AND, OR, and –none–. Choose one of these only if there is more than one validation to the rule.

Note that before a decision relation is assigned a rule, the relation will appear as a red arrow as shown below.

Once a rule is defined, however, that arrow will display green.

Note: A rule does not necessarily have to be defined for any particular relation, but it is generally recommended to do so. If a rule is not defined, then the decision relation will act as a generic relation and send all submission forms through to the next item.

Types of Validations

Validations available to choose from when setting up a relation rule in Workflow Designer are described below.

Review Board – Select this validation when the relation rule is based on the review board to which the submission should be directed. The Value drop down will populate with all of the review boards that are defined in the system.

Review Committee – This validation should only be used if the Review Board Property rb.use_submission_by_committee is set to “Yes”. It is also typically used only for the Initial Review Submission form workflow.

Selecting this validation will result in the submission only routing through the relation in question if they have specified the appropriate review board committee.

Application Form Variable – This validation is based on the value of a form variable in the application attached to the submission.

First, a data value must be selected against which to validate, in the form of an application and a corresponding database column.

After choosing a data value, the Value dropdown will change depending on the data type of the value selected. In the screen shot below, a Yes/No selection data value was selected.

Current Form Variable – This validation is similar to the Application Form variable except that the data values available to validate against are limited to those in the current form attached to the workflow in question.

Current Form - Review Board Selection variable – This validation pulls the Review Board selection variable of the associated form (if one exists).

Selected committee from Action – This validates against the committee chosen from a previous action in the workflow. This rule should only be used if the Review Board Property rb.use_submission_by_committee is set to “yes”.

This would be used to check which committee was used in one of these action nodes: Review Board Committee – Auto Assignment, Return Response and Return Committee. An example would be to set a rule based on a Review Board Committee – Auto Assignment action earlier in the workflow.

 

For example, in the workflow template shown above, Level 1 contains the action node Auto Assign submission to committees. This action is set up to route the submission into one of the two committees for the Review Board. After the submission has been assigned to one of these committees it will reach a decision on Level 2. To send the submission to the first item on Level 3 (IRB Submission Queue), a rule will be defined for that relation in which the submission will only route if the committee auto assigned is Committee 1.

Selected board from Action – This is similar to Selected committee from Action validation except it will use a Review Board as criteria instead of a Review Board committee.

Study Attributes – This validation is based on study attributes such as multi-site site view, multi-site, single study, or exempt.

Submission Attributes – This validation is based on submission attributes such as the outcome action.

Signoff Status – This validation is based on the signoff status of the submission.

Selected Department from Study – This validation is based on the departments associated to the study on the submission.

Workflow Designer Best Practices

The screenshot below displays an example of a workflow (in this case the template for the Adverse Event Form).

Although the workflow designer can add relations within a level, it is not recommended. This can create confusion for the iRIS™ users. Instead, it is highly recommended that another level be created for the second action.

For example, if a user would like to route all Adverse Event Forms from the IACUC Submission Queue node to the IRB Submission Queue node, instead of adding a direct relation between the two in Level 3, best practice would be to use a decision node in Level 4 to send the submission back to the IRB.

In the below screenshot, the workflow is routed to go back to a previous level.