This article uses a narrative example to describe how a typical team would capture, track, and resolve an issue using a typical IssueNet solution and workflows. This article uses an example a change request to one of an organization’s internal web sites. This example illustrates how a user would submit a request and have it routed to a team, how team members would initiate and complete a workflow process, and how reports and metrics would be produced to measure performance.

At Sample Systems, Inc. Doug Pollard, a department manager, needs to have a change made to one of the web applications used by his group. One of the forms used by the application has several fields ordered in a way that is inconsistent with some of their other tools. As a result, a number of entry errors have been made over the last few weeks.

To allow Doug and other business users to submit issues about these internal products Sample Systems has set up IssueNet Relay. IssueNet Relay provides a simple web site Doug can use to browse existing issues he has submitted as well as submit new issues about a variety of IT products and services for which his group are customers.

When Doug launches the IssueNet Relay site he is presented with a screen that allows him to use a list of pre-defined reports to view existing issues as well as a search tool that allows him to run ad hoc searches for issues by keyword. Since Doug’s group is not the only one that uses the web application the search tool allows him to easily search to determine if a manager in another group has already submitted the same request.

The IT group has also enabled IssueNet Relay’s folder view. The folder view allows Doug to simply click on different products and services represented as a hierarchy of issue folders to review previously submitted issues organized into intuitive categories. The folder view also allows Doug to simply click on a folder to submit a new issue about that product or service and have it routed to the correct team.

In this instance the issue has not been reported yet. So, Doug clicks on the new menu to submit a new issue. The menu lists the different types of issues Doug is allowed to submit. The IssueNet platform allows an organization to define unique issue types, and IssueNet Relay can be configured to only allow IssueNet Relay users to submit and view particular issue types. In this instance Doug can submit problem reports and change requests. Each issue type has its own specific form and workflow process.

When Doug creates the new issue he is presented with a form that has a number of required and optional fields. After entering the a short synopsis in the subject field and more detailed time stamped notes in the description, Doug clicks in the documents tab to add a screen capture of the web page in question. To make the process as simple as possible IssueNet platform includes and built-in screen capture utility that allows Doug to add a capture with a couple of mouse clicks.

Now that the issue has been submitted Doug exits Relay knowing that he will receive and e-mail notification once the issue has been through he review portion of the workflow. As necessary Doug can return to the issue to add additional notes and attachments.

In a typical IssueNet solution the submission of an issue will generate a notification for the Primary Contact listed in the issue. In most solutions the Primary Contact defaults to the Primary Contact for the folder the issue was submitted into. This method makes it easy to set up a different responsible party for each type of issue submitted into IssueNet.

Once an issue has been submitted a workflow for that issue can be executed either automatically using an IssueNet trigger or by a user once the issue has been reviewed. In the Sample Systems solution workflows are executed by managers once the issue has been initially reviewed. To execute a workflow a user can select the Actions | Execute Workflow menu option, click the Execute Workflow button on the Actions toolbar or right-click on issues in a list and select the Execute Workflow menu option.

When workflows are executed they generate tasks linked to the issue. These tasks represent the activities that need to be completed to resolve the issue. Because tasks are always organized into projects, when a workflow is executed it will always require that a project for the tasks be selected as well as the workflow. In this case the primary contact for the issue Joe Jones executes the Application Maintenance workflow and selects the project 3rd Quarter Web Site Revision. By selecting a particular project and workflow the tasks the workflow generates will be routed to particular group of IssueNet resources and be governed by specific workflow rules. Projects allow the work on various types of issues to be organized into projects that define available resources and workflows.

When the Application Maintenance workflow is executed a workflow action generates a maintenance review task and automatically assigned the task to Adrian Fripp the Project Lead resource for the 3rd Quarter Web Site Revision project. As soon as the task is created Adrian is notified, and can click on a link in the notification to open the new task. The workflow for this task requires Adrian to select from a set of pre-defined workflow transitions to complete the task. As Adrian selects transitions based on his review the workflow will enforce certain business rules and perform actions to automate aspects of the overall workflow process. To transition the task, Adrian can select the task in his start page and then select the Actions | Execute Transition menu option, click the Execute Transition button on the Actions menu or right-click on the task and select the Execute Transition menu option.

In this particular workflow, if Adrian selects the workflow transition Reject the task will be completed, a workflow action will set the issue status to Rejected, and the submitter and the primary contact will be notified that the issue was rejected in the review process. However, if Adrian selects the Accept transition the task will be completed, but Adrian will be required to enter a time estimate and a completion date and a new implementation task will be generated and assigned to Tanya Deal who is the project’s technical lead. The workflow will also update the issue status to Pending Implementation.

Once Tanya completes the implementation task, actions for that workflow will create a verification task. Once the verification task has been completed from the Pass transition, a task to approve the issue resolution will be assigned to back to Adrian. If Adrian selects the Approve transition the issue will be set to a status of Pending Closed.

As soon as the workflow sets the status to pending closed Doug Pollard, the issue submitter, receives a notification that the issue has been resolved. If Doug believes the issue has not been successfully resolved he can enter feedback in Relay which will also send a notification to Arian Fripp who can then review the comments and reopen the issue by transitioning the approval task to indicate that rework is required. To ensure that no issues are left open indefinitely, Sample Systems has set up and escalation rule using the IssueNet Monitor Service that will automatically closed the issue after 10 days and send a notification to the submitter.

As issues are resolved and tasks are completed IssueNet creates an audit trail that can be used to produce historical reports and metrics. In addition, Sample Systems can leverage the organization of issues into folders and tasks into projects to make their reporting simpler and more powerful. For example, by running reports that break issues down by folder managers can easily identify areas with a high density of unresolved or new issues. By running task reports per project, project managers can easily get estimates on the completion of their projects.

Users can run reports in IssueNet by selecting the File | Reports menu option or by selecting records and selecting File | Print Preview... to produce and ad hoc report. At Sample Systems managers have used the IssueNet Administrator to build several new charts and text reports. Each report has a pre-specified query that allows users to run the report as is. However users can also build their own queries using the Query Builder and Search tools to allow them to produce ad hoc reports at any time.

Although the specific features of each IssueNet solution will be different, this narrative example illustrates the use of features and capabilities common to all IssueNet solutions. This description of a typical workflow process should help you evaluate IssueNet solutions using sample data as well as understand to how implement your own workflow processes.