In a previous article, I wrote about the FogBugz Plugin Architecture, and how it lets us answer some very common customer requests without suffering from feature bloat. In this article we'll examine in detail one of our most popular plugins, Workflow, which does just that.

The Default FogBugz Workflow and Why It's Good

Out of the box, FogBugz provides an intentionally simple workflow for cases. Each case passes through three stages: active, resolved, and closed. When a case is created it is assigned to someone as an active case. When the issue has been dealt with, it is resolved. At that point, it automatically goes back to the original opener so that they can verify the solution. Once they are satisfied, they close the case.

This workflow turns out to work very well for a variety of case types. Bugs start out at a tester or user who found the issue, then go to a developer who fixes it and then resolves it back to the opener for verification. Features begin at the person requesting the feature, go to a team lead or developer to implement, and then end up back at the person who opened it to confirms that the feature meets their requirements.

Furthermore, this workflow encourages a particular way of using FogBugz. It encourages users to verify the resolution of cases, which means more bugs are actually fixed. It also encourages a simple process, so a developer can open a "remember to write the documentation" case without it having to go through six steps of approval. This means that more cases make it into FogBugz instead of ending up as sticky notes all over the monitor.

The default FogBugz workflow: active, resolved, and closed

When the Default Workflow Isn't Enough

Unfortunately, there are some cases where the default workflow breaks down. Sometimes a customer will open a case to report a bug, but they really shouldn't be responsible for verifying it. Often there is a QA person who should be involved in the process for certain categories of bugs. Or a team might want to differentiate between a feature that still being specced and one that is in development.

The default Workflow is very much a 90% solution: it works great 90% of the time (probably more, actually), but that last 10% of the time it just doesn't do what you want. The result is that you end up fighting with the tool, rather than having the tool get out of your way and allow you to get your work done.

At the same time, the last thing we want is for an organization to get FogBugz and then spend a week in meetings drawing flowcharts trying to decide what happens if a bug gets found by a tester in Department A, but it actually comes from a component developed by Department C, so it needs to be verified by the QA teams in both and there's absolutely, positively no way anybody can start creating bugs until this is figured out.

We want FogBugz to JUST WORK, right up until the point where it doesn't, at which point you find the super easy solution we've prepared for you, click a few buttons, and continue on your merry way.

Customizing the FogBugz Workflow

Fortunately, plugins give us a great way to have both simple, sane out-of-the-box behavior, and powerful customization only a few clicks away. For users who don't care or who find that the default workflow is good enough for them, FogBugz continues to work exactly the same. But for the users who need the ability to customize their system, the Workflow plugin can be installed with just a few clicks from the FogBugz Plugin Gallery.

The Workflow plugin allows users to customize workflow in two ways: by defining new categories and statuses, and by specifying how cases are assigned when transitioning a case between statuses.

The Workflow plugin adds a new item to the Admin menu

Custom Categories and Statuses

The first thing to do when customizing the FogBugz workflow is decide what types of cases the customization should apply to. This isn't always as straightforward as it seems. It may seem obvious that all bugs should have to be verified by QA, until you actually implement it and your developers start complaining that every time they create a little case for themselves to remember to fix something it has to be verified by QA. Before you know it, they're back tracking their bugs in notepad and you're amazed at how effective your new process is at reducing the number of bug reports in your software.

Since changing the workflow is potentially so disruptive, we recommend trying out major changes on an entirely new category, which the Workflow plugin makes completely painless to create. In our example, we might create the category "Bug (Needs QA)". Now developers can continue to create reminder cases for themselves that don't have to go through QA, and testers can create cases that will always follow your new workflow. Later on, with just a few clicks you can delete the old "Bug" category if you find you're not using it.

Once you have your categories nailed down, you'll want to create some statuses for them. Here you can take advantage of another new feature in FogBugz 7: multiple active statuses. Before FogBugz 7, all categories only had one active status: "Active". Now using the Workflow plugin it's possible to add multiple active statuses. For example, you could create the "Active (In Development)" status for bugs, or the "Active (Needs Spec)" status for features.

For our example above, we'll add two resolved statuses: "Resolved (Fixed)" and "Resolved (Verified)". When the development team has finished fixing the bug, they resolve the case as "Fixed". When QA has finished verifying the case, they'll resolve it as "Verified".

Add a new category with just a few clicks

Customizing Case Assignment

The other half of custom workflow is defining how cases get assigned when changing the status. In FogBugz 7, each project can have its own workflow. This allows you, for example, to have a special workflow just for the "Inbox" project, or have one workflow shared between all development projects.

Each workflow determines to whom cases are assigned for each status in four different circumstances:

1. Creating or Editing the status of an active case
2. Reactivating a resolved case
3. Reopening a closed case
4. Resolving a case

When selecting to whom the case is assigned, you can choose either a particular user (e.g. "Joel Spolsky"), or you can choose a special value such as "Primary Contact" or "Case Opener", or even "No Change" to keep it assigned to the same user.

You can also choose whether the assignment is forced. Forced assignment means that when the workflow rule is in effect, the "Assign To" dropdown will not be editable. This guarantees that the case will be at least initially assigned to the specified user.

For our QA example, we'll set the rules for our statuses as follows:

When Resolving a Bug (Needs QA),

• Resolved (Fixed) assigns to "Alison Tirrell", our QA lead, and is forced
• Resolved (Verified) assigns to "Case Opener", and is forced

For everything else we'll use the defaults. This will give us the following workflow for cases opened as "Bug (Needs QA)":

1. Case Opened
2. Active & gets assigned to a developer
3. Resolved (Fixed) & gets assigned to QA by the developer
4. Resolved (Verified) & gets assigned to the case opener by QA
5. Closed by the case opener

Using this workflow, we've preserved the original spirit of the FogBugz workflow, where the opener verifies a case, and added a QA step for bugs that need it.

Determine to whom cases are assigned by editing the workflow

What Custom Workflow Isn't

As powerful as this method of custom workflow is, there are a few things that it can't do. It doesn't allow restricting the order that statuses have to go in, so there's no way to say that the "Active (Needs Spec)" status must progress to "Active (In Development)" before going to "Resolved (Implemented)".

It also doesn't allow restricting on users: there's no way to say that only an administrator can close a case, or that cases with the status "Active (In Development)" have to be assigned to a developer.

Also, having a "forced" assignment in the workflow only determines who the case is initially assigned to. Once the case is assigned to a user by a "force" rule, it can be reassigned to anyone (though the original user will always get a notification that the case was assigned to them).

In this, workflow follows the FogBugz philosophy of keep it simple, and stay out of the user's way. If a non-QA user really wants to resolve a case as "Verified", they probably have a good reason to do so. If a user needs to grab a case back after it has been assigned to the Primary Contact for review, they probably know what they are doing better than FogBugz does.

Advanced Custom Workflow

With that said, it is possible to build on the Workflow plugin to create more advanced workflows. If you want to make sure that cases with status "Active (In Development)" are assigned to a developer, you could make a plugin that automatically finds cases in violation of this and reassigns them to an appropriate user.

You could also use plugins to create special virtual users that your workflow assigns to, which have a special meaning in the plugin. For example, you could create a "Case Owner" plugin that adds a new "Case Owner" field to cases, and then lets you choose "Case Owner" as the person assigned to when a case is resolved. Or you could make a "Round Robin" virtual user, and have the plugin distribute incoming cases to one of several users, and use this to handle incoming support requests.

A plugin could even do a similar thing with statuses, by having a special "Next Step" or "Auto" status. When a case is set to the status "Next Step", the plugin takes over and moves it to the correct status and assigns it to the appropriate user.

These are just a few ideas of advanced workflow plugins that could be created. If you have your own idea, you could add it to the Plugin Ideas Forum, or get started writing your own, and of course we'll be happy to answer any questions you might have on our StackExchange site.