Notes About Workflows

The workflow diagram defines the rules and process for an issue to move from creation to resolution:

There are three components of a workflow diagram:

Issue Creation - represented on the diagram by a box with a yellow star at the top left.

Resolution State - represented by a regular box on the diagram.

Transitions between resolutions - represented by directional arrows on the diagram

Each of these components has properties that allow you to define rules for how and who can move issues through the process.

Creating your first workflow

If this is you first experience with RMTrack, please take a moment to read Getting Started with RMTrack.

Before creating your RMTrack workflow we recommend that you take the time to sketch it out first and while doing so ask your self these questions:

What are the roles (Groups) of the users involved in the process?

NOTE: We recommend that you create your groups before creating the workflow.

Who can create issues?
Does someone need to review all issues before assigning them?
What is the process to resolve the issue?
Where and who does it go to after it is created?
Where and who does go to next?
Where next?
Who can close an issue?
Who determines whether an issue can be deferred? Or is a duplicate?

Changing the Workflow for Existing Projects

Special care must be taken when changing the workflow for an existing project. Whether modifying an existing workflow or replacing a project’s workflow with an entirely new one, it is possible to create problems.

Some things to consider:

If issues are in a resolution state that is removed or does not exist in the new workflow they will become 'orphaned'. These issues will have to be moved to a valid resolution state by someone with override workflow project team rights.
Project level e-mail rules that are dependent on particular workflow transitions will be deleted if the modified/new workflow does not have the same transition.
Groups that are valid issue owners/creators in one workflow may not be valid in another workflow.
Rules for the internal Fixed and Valid fields may be different. If an existing project has numerous issues, it may take some time to update these flags based on the new workflow rules.

RMTrack Support recommends the following:

Always do a backup before making significant changes to the workflow.
Do not make workflow changes while users are logged on and actively working with issues.
If possible, create/modify workflows in a test environment first – then migrate the changes to your live environment using export/import workflows.

Please do not hesitate to contact RMTrack Support for advice and/or help with workflow changes.