Workflow allows you to define rules for field access and layout, based on issue criteria rather than the group settings that can be achieved in the field control menu. A workflow rule will enable you to catch flow states of issues and define possible future states or immediate actions based on the current state of an issue.

Common examples include:

Workflow rules are defined by a filter definition that is compared against the state of issues any time data is retrieved or modified. If an issue is matched, a set of requirements and restrictions can be tested, actions can be executed, and field access (controls) or options (flow) can be modified accordingly.

When a rule definition matches the state of a desired issue, the rule's attributes are checked to see if any changes are needed in the regular process. The "Field Controls" and "Flow Control" attributes control any changes needed when viewing/modifying an issue. The "Restrictions" and "Pre/Post Requirements" are checked before any change is made. The "Actions" are executed after a change is successfully made.

The following illustration illustrates the workflow process :

Workflow Attributes

The following table defines the attributes that make up a workflow rule. It is defined by a state definition which is used to determine if the other attributes are to be invoked at any stage in the life of an issue. Restrictions, Requirements and Actions are attributes that are checked when an issue is modified. Flow Controls and Field Controls are attributes which alter the controls available to a user when they are editing/viewing an existing state of an issue

State Definition	The state definition is a filter that is used to identify a state that will be affected by the current rule. Issues are checked against a rule definition to see if the current rule is relevant. Note: - the New Entry option specifies that this rule also applies to new entries into the system. - the New Entry Only option specifies that the rule applies only to new entries.
Restrictions	Restrictions are used to determine what individuals are allowed to move an issue to a given state. If a restricted user tries to move an issue to a state, they are returned an error message.
Requirements	A workflow rule can test that a given set of requirements exist, before allowing an issue to reach a given state. Requirements are defined as a filter, just like the actual workflow definition. If the requirement filter is not passed, the user is returned an error message Pre Requirements are tested before any changes are made to an issue to ensure that the requirements are met before an edit is performed. Post Requirements are tested to determine if the post state of the issue will meet a set of criteria after a change is made.
Actions	If the new state of an issue matches a given workflow definition and the requirements and restrictions are passed, then a set of actions can be performed on the issue state change. The Action Notify List is used to notify users of this state change. The AutoChange field will change the value for a field to the indicated value. You can use existing bug attributes in workflow autochange. (ie: re-assign to creator by autochanging assignedTo field back to <SUB bs.mEnteredBy> See full list of bug attributes in Rank docs.
Flow Control	Flow Control limits the list options for the given state. The example given says that for a bug in the [Ready to Release] state, the only selectable options that will show up will be the ones listed: "Closed", "Deferred", "Ready For Release", "Ready For Retest", "Rejected" You should include the one in the state definition, because it is the one that needs to be defaulted to. If it is not present, the first one in the list will be selected by default and may not be noticed. Alternatively, you could make it an always mandatory field, so that something is always chosen.
Field Control	The workflow field controls are used to control field attributes for the current state. This option expands the Field Controls menu in the Admin menu which is limited to group sets. The Mandatory setting forces users to enter data in a specific field. This option adds an exclamation image in front of a mandatory field so that it is obvious to the user. If the user does not edit the field, they are presented w ith an error message and must hit the back button. There are two classifications of the mandatory setting. The Yes option forces a user to submit data when a new bug is created. This is useful to ensure that u sers add enough information for a new issue and do not accidentally enter the de fault setting, or leave an important field blank. The Always option takes the fu nctionality one step further, by ensuring that data is entered at every step. This is extremely useful for the AssignedTo field so that the correct person is sent the notification on every update. Without this setting, an updater may for get to change the user name and the notification may never be sent. Field data can also be restricted using any of the following options: The Read/Write (R/W) option is the default for all editable fields. This option allows a field to be read and modified on any update. The Read Only (RO) option restricts a group to reading privileges only. The Hidden (H) option hides a field all screens. The After Create (AC) option restricts reading priveleges after the issue is created.

Order is Important

The rules are arranged in a lookup order that is used when determining if an issue state matches any existing workflow rules. When a match occurs, that workflow rule is used to control what actions to take for an issue. The remaining rules are skipped.

Examples

The following example shows you how you can implement the default flow states that are listed in our product overview. (http://www.fastbugtrack.com/info/overview.html)
It also shows you how you can restrict the Closed state.

Process Example (click for larger view)

Multiple ways to do things

There are always a number of ways to enforce a given rule. You must determine the best method in your case. As a rule, the after the fact states are the simplest to implement (Restriction/Requirements) as they simply give an error message when a rule is not allowed. The pre state attributes (Field Controls/Flow Controls) allow you to do more complex rules (especially for enforcing flow) but they will take more rules to implement what you want.

For example, restricting the Closed state can be done in the following ways:
A - definition: Status=[Closed] and PostRequirement: LoggedIn=[AllowedUser]
B - definition: Status=[Closed] and Restriction: Access=[AllowedUser]
C - create two rules for all other states. One for the AllowedUser, which included the Closed option in Status flow. The other for all other users that do not have access, without the Closed state in the Status flow.

Options A/B can be done with one simply rule.
Option C will allow users to see their true options before hand, rather than simply getting the error message after the fact.