As an issue management platform, IssueNet has basic features designed to allow organizations to submit issues, route them to the correct parties, and implement workflows that model realistic business processes – regardless of industry or process.

As an issue management platform, IssueNet has basic features designed to allow organizations to submit issues, route them to the correct parties, and implement workflows that model realistic business processes – regardless of industry or process.

To achieve this Elsinore designed IssueNet using a workflow model based on a distinction between issues and tasks. This model was based on years of user feedback and had the following objectives:

• To support the work of multiple resources on individual issues concurrently or in series.
• To simply the workflow process for each individual resource working on an issue by decomposing a larger workflow into a series of task specific workflows.
• To allow a single issue to be resolved multiple times in seperate deliverables without duplicating the issue.
• To provide better rollup reporting per issue based on the work of multiple resources.

The IssueNet workflow model treats an issue as a description of what is to be resolved and tasks as activities initiated to resolve the issue. In other words you could describe IssueNet as having an activity based workflow model.

In a typical workflow process the issue would be used to record the description, attributes, and supporting documentation. Tasks would be created and linked to the issue to manage the workflow activity and document activity based information such as estimated and actual hours as well as the current percent complete.

In a typical IssueNet workflow you would expect to see the following type of issue and task structure:

• Issue: Implement a medium priority service request based on a description, attributes, and documentation added to the issue.
  • Review and approve or disapprove issue
  • Implement resolution based on approval
  • Verify successful resolution of the issue
  • Document issue resolution
  • Close issue by submitter

Tasks are the primary workflow items in IssueNet. Workflow transitions are executed from tasks. Tasks linked to issues drive the workflow process and update and close issues as steps in the workflow are completed.

Each workflow is composed of a series of states and transitions as well as actions and conditions. If you logon to the Administrator and open a workflow you will be able to view the state and transitions as well as the action and conditions linked to the elements of the workflow.

Actions are essentially commands which instruct IssueNet to perform an action. IssueNet support pre-defined action types for common operations like sending a notification, creating a new item such as a task, or updating the status of an Issue. For less common or more sophisticated actions IssueNet can also run a script.

Conditions are statements that can be linked to workflow transitions and be evaluated to a true or false value. When used in workflows conditions provide for the enforcement of business rules. If a used selects a workflow transition and the condition evaluates to false, the transition will be prevented and the user will be informed will a message indicting the reason the condition failed. A typical workflow condition would be one that ensures that a user has entered a value in a field before allowing a task to be transitioned from one state to another.

The best way to familiarize yourself which how to design and modify workflows is to open an existing workflow in the Administrator and step through the workflow states and transitions and reviewing the types of actions and conditions linked to elements of the workflow. Start by clicking on the workflow diagram and then look in the properties window for actions linked to that element. Clicking on the ellipses button in the Actions row will display the detailed information about the actions linked to that element. Similarly, clicking on a workflow diagram or a transition will allow you to click in the Conditions row to view a condition linked to that element. Follow the states and transitions of the workflow from the initial state to the terminal states. Once you have reviewed several workflows you should begin to see common patterns and methods of constructing workflows.

The actions and conditions linked to a workflow are executed and evaluated as a user transitions a task through a workflow. The process by with a workflow performs these executions and evaluations follow a set of simple rules:

By understanding these five principles and the types of actions and conditions that can be added to workflows, states, and transitions, you can implement an infinite variety of workflows and business rules specific your organization’s processes.

• Actions added to a workflow diagram are executed when the workflow is executed. A typical action added to a workflow diagram would be used to create a task bound to that workflow.
• A condition added to the workflow diagram will be evaluated when the workflow is executed and will prevent the workflow execution if it evaluates to false. A typical condition added to a workflow diagram would be used to check the security group membership of the current user and prevent the workflow from being used by particular groups.
• Entry and exit actions added to states are executed when a transition is taken into and out of a state. Actions added to states are most useful when you want an action such as a issue status update to always occur regardless to the transition taken into or our of a state.
• Conditions added to transitions prevent the transition from being completed if the condition evaluates to false. A typical condition added to a transition would be used to require the user to enter estimated hours on a task before it can be transitioned from one state to another.
• Actions added to transitions are executed when the transition is taken to the next state. Actions added to transitions are most useful when you want an action, such as an action to create a new task, to only occur if a particular transition is taken from one state to another.

As described above, IssueNet manages workflow through issues and linked tasks. Like any system, IssueNet must provide a method for categorizing and organizing issues and tasks in a way that will support routing, reporting, and workflow processes. To accomplish this IssueNet products organize issues into folders and tasks into projects. Folders and projects can be nested hierarchically to allow issues and tasks to be organized in an indefinitely deep hierarchy of projects.

This method of organizing issues and tasks has a several advantages over systems that do not provide a hierarchal system of organization.

How IssueNet organizes issues and tasks allows an organization to clearly distinguish and metric the difference between what issues are reported about and the effort, in terms of tasks, initiated to resolve those issues. At typical example would be the requirement to track issues submitted by product module or functional area combined with the requirement to organize work on those issues by project or team. The folder and project structures allow organizations to track both issue density and frequency as well as how work on issues are organized into task based projects.

The project organization typically has requirements that are quite different that how the submission of issues are tracked. For example, issues submitted about different functional areas of a product line or a service may be worked on by different teams with different timelines, workflows and resources. IssueNet allows an organization to clearly and simply measure both what issues are submitted about and how they are resolved.

Issues submitted into the same folder may be resolved by different teams with different workflow and resource requirements. For example, different issues submitted about the reporting services of a product may be resolved by new development, maintenance teams, or customer service based on the outcome of the issue review process. IssueNet allow these issues to be resolved by different resources with different workflows while still preserving clear information about why the issues were submitted.

Therefore, one of the first tasks in setting up a new database for production use is to define folders and projects. If you installed sample data these elements will already exist. If you have a new database you should set up folders and projects based on how you anticipate using IssueNet. However, do not worry about the decisions you make. It is simple to re-name and re-arrange folders and projects. We do, however, recommend that you create a single top level folder and project. Because permissions can be applied hierarchically, a single parent folder or project makes it easier to apply permissions.

IssueNet is designed to allow you to easily track team member assignments as well as other individuals who are issue stake holders. To accomplish this IssueNet distinguishes between contacts and resources. Any individual can be an IssueNet contact – a user or a non user. Contacts can be associated with issues and receive notifications.

However, tasks are assigned to resources and a single contact can be linked to multiple resources. A resource is a relationship between a contact and a role. This design allows a single contact, which is a single user, to play multiple roles.

Because tasks are assigned to resources, one of the first tasks for setting up a new IssueNet database is to use the IssueNet Administrator to set up new resource roles, and the IssueNet Client to set up new resources. Once resource and resource roles are defined you can tailor your workflow rules to dynamically assign tasks to resources based on role.

In order to master the basic concepts necessary to use, modify, and create IssueNet based solutions, administrators should:

• Create an additional database loaded with sample data that allows you and other users to exercise the fundamental workflow features of IssueNet with no additional configuration.
• Add folders and projects your production database to allow you to submit new issues and create tasks.
• Add new resources to IssueNet and assign them to projects in your production database.
• Add workflows to projects in your production database.
• Modify and create workflows in your production database and test them with the folders, projects and resources you have created.

Once you have reviewed the basic workflows that ship with IssueNet, and have created your own workflows based on your folder, project and resource definitions, you are ready to address more sophisticated workflow definitions.