Edit1 What are Actions?
An IssueNet Action is a command that directs IssueNet to perform a particular task. Actions are designed to provide a simple way to automate common business processes. IssueNet supports various types of Actions modeled after common tasks. Once an Action has been created it can be reused throughout your business process. Actions can be executed by workflow states and transitions, by Triggers when users create or modify items, and by Triggers scheduled by the IssueNet Monitor Service.
Edit2 Types of Actions
IssueNet supports the following types of Actions:
Edit2.1 Conditional Actions
Conditional Actions provide a way to execute actions based on the evaluation of a condition. Each Conditional Action consists of a condition and either a true action or a false action. When a Conditional Action is executed the condition is evaluated. If the condition returns a true value, the true action is executed. Likewise, is a false value is returned, the false action is executed.
To create a Conditional Action, simply choose the condition you want the Conditional Action to evaluate, and the true and false actions you want to be executed based on the return value. Both the true action and the false action are optional. You can choose to specify either or both.
Conditional Actions are most useful in circumstances where you want to add conditional logic to a workflow state or transition. For example, suppose you have a task to review an issue, the task workflow includes a transition that indicates implementation approval, and you want to create an implementation task based on the transition. If you simply wanted to create the same task every time you could simply attach a create object action to the transition. However, suppose you want to create a different type of task based on the issue priority or the type of issue based on class. In this instance you should create a conditional action that evaluates the condition you are interested in, specify the actions that create the tasks based on each outcome, and relate the conditional action to the transition.
The example below will create a task if the issue is a Software defect:
 Conditional Action |
Edit2.2 Create Object Actions
One of the features of IssueNet workflows is the ability to automatically create tasks, issues, and other items based on workflow rules and triggers. Create Object actions provide a simple form you fill out to define the kind of item you want IssueNet to create and the properties you want it to have.
To create a new Create Object action, begin by selecting the type of object you want to create. Beneath the box for selecting the object type there is a box that allows you to set a variable name for the object. The variable name is optional. Variable names are useful in instances where you want to reference the new object by name in a workflow process.
Once you have selected the type of object you want to create, the action form will display the properties you can set when the action is executed. You can set the properties using literal values. For example, you can set the AssignID of a task to be a specific resource by selecting Edit and picking it from a list. However, in most instances you will want to set the property values using variables. For example, to set the AssignID to the resource with the role project lead, you would select Edit, select Variable as the type of value you want to specify, and enter the following variable:
WorkflowProject.Resources[Role='Project Lead'].ObjectID. When adding variables to Create Object actions, the Variable Editor will help you create a variable with the correct syntax.
The example below will create a Task to fix a Software Defect:
 Create Object Action |
Edit2.3 Execute Transitions Actions
Execute Transition actions allow you to further automate your workflow process by allowing you to use workflow states and transitions as well as triggers to transition tasks automatically. For example, suppose you have two tasks linked to an issue: One task is an implementation task and the other is created for verification of the implementation. If the verification task is transitioned to indicate verification failed, it would be common to want to indicate that the implementation process needed to restart. You could have the workflow automatically create a new implementation task or you could transition the implementation task manually. However, a better solution would involve having the verification task automatically transition the implementation task to a state such as Re-Open.
Execute Transition actions can also be used with triggers. Suppose you want to automate a rule that all tasks that have been in a state of Pending Signoff should be transitioned to Completed if the task is more than three months old. By creating a trigger linked to a monitor event, the trigger can execute the task transition automatically to the correct state.
An Execute Transition has two required elements: the task the action will act on and the name of the transition that will be executed. The task required by the Execute Transition action is specified as a variable. To specify a variable, select Variable from the type box and use the variable editor to build a variable. The transition name is specified by simply typing in the name of the workflow transition. Specifying the transition name requires that you have some knowledge of workflow to which the task is bound.
The example below is an action that executes the make corrections transition on the predecessor of the current workflow task:
 Execute Transition Action |
Edit2.4 Execute Workflow Actions
Execute workflow actions allow you to have workflows executed automatically by other workflow states and transitions or by triggers. The automatic execution of a workflow can be useful when you want an event, such as the insertion of a new issue, or a workflow transition to determine when a workflow is executed.
When a workflow is executed, certain contextual information is required. Every Execute Workflow action has three elements:
- The workflow to be executed
- The current project
- The current issue
In addition to specifying the correct workflow, this information supplies the correct issue and project context for common workflow actions such as creating tasks. This is the same information that would be required if you were to execute a workflow manually from within an IssueNet client.
Like elements of other workflow actions, the workflow, project, and issue required by the Execute Workflow action can be specified as either literal values or variables. To specify a literal value, select Object from the Type box and then click the Select… button to pick the object based on a query. To specify a variable, select Variable from the type box and use the variable editor to build a variable for each required element.
The image below will Execute the Change Manager Signoff Workflow:
 Execute Workflow Action |
Edit2.5 Invoke Script Method Actions
In some instances you may want to use a script as a part of your workflow to define and enforce more complex business rules. To allow you to easily execute a script from a workflow action, workflow transition, or a trigger, IssueNet provides the Invoke Script Method action.
Using the IssueNet Architect you can create a script that is included in a solution. In the form for the Invoke Script Method action, you specify the portion of the solution script you want the action to execute by typing the name of a method in the script you want the action to execute.
Edit2.6 Link Object Actions
Link Objects Actions are used to create links between two objects. A link binds two objects together on a given relationship. A link can optionally include a reason field to indicate why the two objects are linked. The parameters required by the link object action are the relationship name, link from object ID, link to object ID.
Edit2.7 Modify Object Actions
Modify Object actions provide a simple way to set properties of items such as issues and tasks using workflow states and transitions as well as triggers. For example, a modify object action can be used to automatically update the status of an issue based on the completion of linked tasks or to set the percent complete of a task based on a workflow transition.
To create a new Modify Object action, begin by selecting the type of object you want to create. Beneath the box for selecting the object type there is a box that allows you to set a variable name for the object. The variable name is optional, but may prove useful in instances where you want to reference the new object by name in a workflow process.
Once you have selected the type of object you want to create, the action form will display the properties you can set when the action is executed. You can set the properties using literal values. For example, you can set the AssignID of a task to be a specific resource by selecting Edit and picking it from a list. However, in most instances you will want to set the property values using variables. For example, to set the AssignID to the resource with the role project lead, you would select Edit, select Variable as the type of value you want to specify, and enter the following variable:
WorkflowProject.Resources[Role='Project Lead'].ObjectID. When adding variables to Modify Object actions, the Variable Editor will help you create a variable with the correct syntax.
The example below will set the Issue Workflow Status to Implemented:
 Modify Object Action |
Edit2.8 Send Notification Actions
Send Notification actions provide a simple way to send notifications to IssueNet contacts using a specific notification template and e-mail priority. Like other actions, send notification actions can be executed by workflow states and transitions as well as by triggers. For example, adding a Send Notification action to a workflow state or transition provides a simple way to notify contacts about workflow events such as the completion of a task or a transition of interest.
Adding a Send Notification action to a trigger is useful for sending notifications on events like the creation of an issue or a task or for sending escalation notifications using triggers that are executed by monitor events.
Additionally, Send Notification Actions contain the Template which will be used to send the Notification. For more information on Template Editing, please consult the Notification Templates portion of the
Reference Materials.