Knowing the current responsibilities of your support team—firstly, maintaining the high level of service you are providing to your customers—is incredibly important. There are few things in support more painful than getting a call from a customer requesting the status of an urgent case, only to realize that their ticket was completely overlooked and hasn’t been touched since last Thursday. Ouch.

After our first post on how we implement customer service, Fog Creek’s Email Workflow, we had several customers ask how we prevent cases from falling through the cracks. For example, if a customer replies to a member of our support team who is now out of the office, how do we make sure the customer gets a timely response?

We have several mechanisms for keeping an eye on cases, but the most notable one is having multiple filters in FogBugz and having someone on the team whose job it is to check those filters periodically.

The Role of the Team Lead

We’ll look at which individual filters we use in a minute, but the key here is to note that we have an individual whose job it is to check these filters to make sure the support machine is humming along smoothly. This lets the other team members focus on the work at hand, namely, solving customers’ problems, without having to worry about management minutiae. Some of the things the Team Lead does:

• If someone is out of the office, assign their cases to Up for Grabs
• Make sure Fix it Twice cases actually get fixed (or get “won’t fix”-ed)
• Make sure Tech Calls don’t get overlooked
• Help out overloaded support team members
• Make sure cases don’t become overdue

At Fog Creek, we have a dedicated support team lead, Derrick, who is responsible for these tasks. You could just as easily rotate these responsibilities on a day-to-day basis between various members of your team.

Let’s start by looking at a few of the shared filters we use:

Filter: Next Due Cases

The Next Due Cases filter is the most important filter for our support team because it represents our commitment to respond to all incoming inquiries within one business day. As such, it gets checked more frequently to make sure we’re responding to customers in a timely fashion.

Another import use of this filter is looking for fires (). If you check this filter first thing in the morning, you might be able to spot common themes, alerting you to a larger issue that needs to be brought to the immediate attention of the engineering team.

Also, since we modified our Inbox workflow so that when a customer emails in, the case gets assigned to the support rep who last sent the email, Derrick will use this filter to re-assign cases to Up for Grabs so that another team member can pick up the case.

Filter: Tech Calls

I blogged about how we schedule tech calls and this filter shows upcoming calls:

This filter gets checked relatively frequently to make sure that calls aren’t being missed. If a call is still open, but past due, it’s possible that someone just needs to respond with the tftc snippet (thanks for the call) and close the case.

Filter: Fix It Twice

Having an area in FogBugz to dump “fix it twice” cases keeps your support team productive (read the “Fix everything two ways” section of Joel’s Remarkable Customer Service article for more details). Let’s say you get off the phone with a customer, and it’s clear from the nature of her issue that there’s a hole in your documentation. At this point, you could:

• Fix the documentation now or
• Make a note to yourself to fix the documentation later

If you’re blazing through your support queue and want to make sure you service all of your customers, you should create a new case in a Fix it Twice area to handle later, once you’ve finished responding to customers (since this fix is important, but not urgent). Here’s a glimpse at our current Fix it Twice filter:

Derrick will check this filter periodically to make sure it doesn’t just build up over time. He might put an edit in a case to ask when something can get done, at which point the person who opened the case might fix it if he has time or mark the case as “Resolved (Won’t Fix)”. By the way, this is an entirely reasonable action. Sometimes what seems important now doesn’t seem as important after you’ve been away from it for a while.

Filter: Known Issues

Another useful filter we keep around is the Known Issues filter. This is the only one of the shared filters that we have set up in Outline ( ) mode. When a new case comes in that matches the known issue, we’ll make it a subcase of the known issue. This allows us to gauge how much of our customer base is being impacted by a particular issue.

When Derrick looks through this filter, he’ll close Known Issues that have been fixed and if a particular issue is becoming more widespread, he’ll contact the appropriate team lead to see if a fix is on the way.

Filter: Onboarding

An onboarding filter helps you monitor the replies of a new team member so you can offer technical advice, tweak style issues, and in general make sure that onboarding is progressing smoothly.

The above filter shows all cases edited and resolved by Sonny that are unread (color:blue indicates unread cases). Once Derrick reviews a case, it no longer shows up in this filter (unless, of course, Sonny edits it again) and he can move on to the next case.

Personal Filters

The above filters help to monitor the workload of the entire team, but each individual team member should be using personalized filters. Ideally, when onboarding a new team member, you’ll supply him or her with a few basic filters to get started, expecting the filters to be customized over time.

You’re probably going to want specific filters that represent your major areas of responsibility, but it’s also worthwhile subdividing your My Cases filter to remove unnecessary noise. As someone who works both on the support team and on strategic work for the company, I end up with a My Cases – Queue filter as well as a My Cases – Strategic filter. The latter is simply an inverse of the former. It took me over a year to figure out how I needed to divide the cases—not to mention the search string is incredibly ugly—but it’s worked really well for me.

Filter: My Cases – Queue (Flat)

The My Cases – Queue filter represents any work I would do when I put on my support engineer hat, e.g. incoming emails, tech calls, etc.. Being the end of the support day when I grabbed this screenshot, the filter is a bit bare, but you should get the idea.

It’s worth noting that I’m using a Flat view instead of an Outline view. This favors working quickly through a list of disparate cases, which is exactly the purpose of a having a Queue filter.

Filter: My Cases – Strategic (Outline)

The queue that represents my strategic work is essentially an inverse of my Queue filter (wrap everything in parentheses and put a “-“ in front of it). The Strategic filter, however, uses an Outline view, which makes it much easier to visually group cases together in a parent/child relationship. When I’m not wearing my support engineer hat, this is the first filter I check to see my current area of responsibility outside of the queue.

Filters to Meet Your Needs

The filters we have set up work really well for us, but of course they are tailored to our needs. If you are using FogBugz for customer support, you will want to set up filters that give visibility to how well you are servicing your customers as well as the overall health of your support team. Encourage each team member to set up personalized filters that represent their current area of responsibility while simultaneously removing noise. This keeps your team focused and servicing customers effectively.

In our series on how Fog Creek does customer service, we’ve looked at our email workflow and how we use snippets for better customer service. Another “feature” of our support team is that rather than taking tech calls as they come, we schedule them, and this post explores the why and how of that process.

Software Companies Have Layers

Our support team is a major part of the implementation layer that shields developers so that they only have to worry about writing code. When a customer calls in screaming about why-oh-why do you not have an importer yet for VisiCalc, it’s only been around for several decades, and if only you could write it for me this afternoon I could bring my development team into this century, and oh-by-the-way how do I use FogBugz scheduling when I have eighteen dependencies—when that phone call comes in, our developers don’t even know about it because our support team is protecting them from it.

But we also protect our support team. When a call comes in, our adroit office staff will answer with something like:

“Fog Creek Software, how can I help you?” …

“Do you have an existing case number?”…

“I don’t have a tech support rep available at the moment; can I schedule you for 3:30 this afternoon? If it’s an emergency, I can put you down for ASAP and someone will call you right back.”

This process works really well. While there might technically be a support rep “available” in the sense that he’s not on the phone, he’s not “available to provide the best quality of service.” Support engineers, like your developers (and anyone else doing highly technical work), work best when they’re not interrupted. If you patch the customer straight through to support, they have to stop working on pinning down a repro of that nasty email bug—which, by the way, your crack support engineer is working on to let your developers focus on shipping new features—and when they pick up the phone, their first thought is “how do I get off the phone so I can continue what I was working on.”

On the other hand, if you schedule a call, the support engineer can read the note in the case (e.g. “Customer says he can’t deactivate users”), collect himself, and give the customer his complete attention when he calls him back. This makes a world of difference in the emotional well-being of our support team as well as the level of service we are able to provide to customers.

How We Schedule Calls

When we’re ready to schedule the call, we use a simple scheduling form that creates a FogBugz case. The form is trivially simple with each time slot simply redirecting to FogBugz with a bunch of fields filled in (it works the same way as Bookmarklets).

The case goes into the Sales & Support Project (separate from Inbox), in the Tech Calls Area, gets assigned to the Up For Grabs users, with the Due Date set to the call time.

In the screenshot above, you’ll notice that the case is assigned to Derrick Miller, even though we originally assigned the case to Up for Grabs. This is because we have a simple FogBugz plugin that round-robins the calls assigned to Up for Grabs to the next available support rep.

Don’t Miss a Call

Once the tech call case is created, we want to make sure that the support rep assigned to the case doesn’t miss it. We have several safeguards in place to make sure tech calls don’t fall through the cracks:

• Change your FogBugz filter. Sort the cases for your support queue filter by Area first so that Tech Calls show up grouped at the top.
• Add email filters. Create a Gmail or Outlook filter that identifies Tech Calls and gives them a big fat green (or red) label.
• Set up a 42” TV in your support area that shows upcoming calls. This lets the entire team see the calls to make sure one doesn’t get missed.
• Other custom notifications, such as Growl for your desktop or Pushover for iPhone (this is trivially easy to set up with the FogBugz URLTrigger Plugin).

Why so many types of notifications? Since we’re not interrupting the support team when the actual call comes in, we want to make extra sure we see the call once it is scheduled. Some team members use lots of notifications. Personally, I just rely on my FogBugz filter and a Gmail filter that adds a “Tech Call” label to Tech Call case notifications.

Or Avoid the Phone Altogether (If Possible)

Another reason we schedule calls is so that we can contact the customer by email first to possibly resolve the case or gather additional information which will help us to prepare for the call. Granted, some things are inevitably best handled on the phone with a Fog Creek Copilot screen-sharing session, but you may be able to email the customer ahead of time, solve their problem, and avoid the need to get on the phone. Often this leads to a faster resolution for the customer and less interruption for the support engineer.

If I receive a call and recognize a known issue, I might respond with something like:

Hi Adam,

Thanks for calling Fog Creek!

I see we have a call scheduled for 2:00 PM EDT to discuss an issue you’re having with deactivating users in FogBugz. In preparation for the call, could you share additional details about the problem you are having?

Also, which version of FogBugz are you using? I know the latest version of FogBugz fixes a bug related to deactivating users, so you might try upgrading to see if that fixes it.

All the best,

Ben McCormack
Fog Creek Software

Very likely, if I’ve diagnosed the issue correctly, the customer will email back that upgrading fixed the problem. If not, we’ve hopefully collected some information from the customer that helps us prepare for the call and thus reach a quicker resolution.

It’s All About Better Service

Scheduling calls is an integral part of our efforts to provide remarkable customer service and works very well in supporting our highly technical products. Because our support engineers are protected from immediate interruptions when calls come in, they are in a much better position to serve the customer when they get on the phone. Our customers know that when they receive a call back, they will be speaking to a competent individual who can solve their problem.

In our last post, we took an in-depth look at Fog Creek’s email workflow. This post is going to take a look at how we use snippets to save time when corresponding with customers.

When used appropriately, snippets can improve the level of service you provide to your customers, helping you to quickly handle the eighty percent of cases that require routine support, giving you more time to focus on the twenty percent of cases that might need advanced troubleshooting and a more detailed response.

Snippets for (almost) everything

Snippets make routine support a breeze. Not only do they decrease the time it takes to respond to a customer, but they also serve as a way to capture common support knowledge. We use snippets for just about everything, from salutations and signatures all the way to less common scenarios that are just frequent enough to merit having a well-prepared canned response.

Don’t get me wrong—just because a snippet is ‘canned’ doesn’t mean it has to be impersonal. For example, if a customer sends us an email requesting FogBugz support and I need additional information from them, I might type the following response, where ` is the snippet key:

1`

env/fb`

sl`

The first snippet is our default salutation, the second asks about the customer’s FogBugz environment, and the third is my personal signature. They get translated to:

Hi {firstname},

Thanks for writing to us!

Could you answer a few questions for me about your environment?
- Have you made any major changes recently to your FogBugz installation?
- What version of FogBugz are you running (Help > About FogBugz)?
- What database server (and version) are you running?
- What OS are you running?

All the best,

Ben McCormack
Fog Creek Software

Since we’re using a custom placeholders BugMonkey script, {firstname} also gets replaced with the customer’s first name. In the end, the customer gets a personal, detailed email and I’ve barely had to do any typing. The last two snippets I used above are personal snippets that I’ve saved in My Settings > Snippets, but we also have tons of shared snippets as well.

Let’s take a look at five ways that we use snippets at Fog Creek.

1. Faster Typing

The best place to start to get a quick win from using snippets is to introduce simple abbreviations that replace common words and phrases in your everyday correspondence. We have basic snippets such as fb (FogBugz), fbse (http://fogbugz.stackexchange.com), or p (1-866-FOG-CREEK (1-866-364-2733)), but we also like to replace common phrases that come up frequently:

• joel – “Hi {firstname}, Joel passed along your email and asked me to get back to you.” We have a ‘name’ snippet set up for every member of our team.
• callme – When a case needs to be escalated to a support call, the callme snippet explains what to expect during the call and how to set it up.
• tftc – “Thanks for the call.” After wrapping up the call, we use this snippet, usually with additional details about what we covered during the call.
• record – When we need a screencast to demonstrate an issue, we use the record snippet to request it, which includes instructions to make sure the screencast gets appended to the case.

2. Common Support Scenarios

Snippets aren’t just for typing out emails faster. They’re also a place to store answers to common support inquiries.

• benign – This snippet communicates that the exception you’re seeing is entirely harmless.
• bug – Did you find a bug? Thanks! Once we’ve filed a case, we use this snippet.
• fb/api – The FogBugz XML API is a great way to extend your use of FogBugz, and this snippet provides the links to get started.
• od/access – If you’re having an issue with your On Demand account, we’ll always ask your permission before inspecting your data.

You may have noticed that we used fb/ and od/ to prefix two of the snippets above. We use this convention to group common snippets together, making them easier to find and remember.

3. Uncommon Support Scenarios

Having snippets for common support scenarios is valuable, but it can also be beneficial to have snippets to handle the uncommon cases. Although these situations don’t come up often, having a carefully crafted response that’s been iterated on multiple times often leads to a quicker resolution of the problem.

• 250OK – Although it’s rare, customers will sometimes contact us to let us know that they’re not getting notifications from FogBugz. After verifying that the message was delivered from our servers, we offer this kindly-worded snippet to guide the customer to their next step in troubleshooting.
• idontspeakgerman – If someone writes to us in German, the least we can do is respond auf Deutsch.
• eml – FogBugz used to have issues parsing certain types of email messages (the product has gotten much better, so we don’t see this as often). When this happened, this snippet would tell the customer how to get the source of the message to send to us.

4. Sales

The sales team also uses snippets:

• churn – If a customer stops using FogBugz On Demand, we might send them a quick email asking them why they left us.
• expired – This snippet covers what’s included in your maintenance contract and encourages customers to renew their maintenance.
• free – It took us a while to realize the need for this snippet, but boy does it save us a lot of time! It lets customers know everything we offer for free.

5. Not Us

Sometimes people contact us and we’re simply the wrong company to answer their inquiry. Rather than say “We can’t help you. Go away!”, we have snippets to handle these occasional emails so that even if they never come in contact with us again, at least they walk away with a positive impression of Fog Creek.

• consult – We’re flattered that people want us to write custom software for them, but we’re honestly not the right company.
• notus – Sometimes the email is so vague that we’re not sure if the correspondent is talking about one of our products. This snippet can quickly straighten that out.

6. Bonus!

While searching through hundreds of snippets, I came across two gems which I’ll include inline for your enjoyment.

fogcreek:

It is a place in Saskatchewan, where, from 1962-1965, some of the leading minds in computer science gathered each summer to discuss advances in algorithms and bug tracking. The Group of Fog Creek (as they were known) stopped meeting after several of their members, including professors from Dartmouth, MIT, and the New Mexico School of Mining and Technology, were savagely mauled in a horrible attack by black bears. Our company was named as a tribute to these victims, who gave us such technologies as the preincrement (–i) operator, the use of ^H to denote overwritten “humorous” text, and several new prime numbers, including 8739873298781248781.

(Not a true story. 8739873298781248781 is not even prime.)

kiwi:

Once upon a time, a kiwi came poking around Fog Creek because he realized he had a bug.  He said, “I am a bird that can’t fly, this can’t be by design!”.  He was hoping that someone here could figure out what the nature of the bug was, and how to fix it.  And so he sits atop FogBugz waiting and watching for someone somewhere to figure it out, and mark the case of the flightless bird Resolved(Fixed).

This is only a small sample of the hundreds of snippets that we have set up in FogBugz. Snippets don’t have to be used exclusively for customer support. Any time you edit a case in FogBugz, you have an opportunity to use a snippet. Maybe you use one as a template for filing a bug report or as way to standardize particular workflow steps. Regardless of how you use them, snippets will help speed up routine work so you can devote your time to more detailed efforts.

Many of our customers have asked us how Fog Creek does customer service. Joel has already written a great article on Seven steps to remarkable customer service, which can be put in place at any company. We also wanted to share some of the specific customer service implementation details put in place here at Fog Creek. This post—the first in a series on customer service—will go into detail about how we handle email support.

Posts in this series:

• Fog Creek’s Email Workflow (this post)
• Better Customer Service with Snippets
• Schedule Calls, Protect Your Support Team
• Know the Responsibilities of Your Team
• Big Board: Having Fun with Data

A Quick Video Tour

This video provides a quick walkthrough of how a support email gets processed once someone submits an email via the contact form on our website. If it feels a bit rushed, don’t worry; I will explain everything in detail below.

Email Set Up

We primarily try to channel our support inquiries through email and we use FogBugz to handle all customer support messages. While we use Google Apps email to receive notifications and for personal communication, everything customer-related is almost exclusively handled through FogBugz.

Within FogBugz, we have a single Inbox project for our current paid-for products (FogBugz, Kiln, etc.) with cases automatically sorted primarily into either a Sales or Support area. Since we strive to respond to each customer email within one business day, we turn off the auto-reply for each of our mailboxes and set the due date to 7 Working Hours.

We also made a small modification to the default workflow so that when the customer responds, the case will be assigned to the person who last emailed the customer.

How Customers Email Us

Customers can either email us directly at customer-service@fogcreek.com or they can fill out a form on our website, which will send an email to a mailbox that’s monitored by our FogBugz instance.

You might also notice a “Record a screencast” button on our Email Us page. This button uses Screenr Business to help the customer record a screencast of their issue. Once the screencast is submitted, Screenr sends an email to customer-service@fogcreek.com with a link to the Screencast. We love this feature because of how quickly it can speed up the “Oh that’s what’s wrong!” aspect of troubleshooting.

No Cherry Picking

We set the primary contact for the Inbox project to a user called ‘Up For Grabs.’ To discourage cherry-picking, we run a random assignment script every hour, which looks for cases assigned to Up For Grabs and reassigns them to members of our support team (we have a similar script that runs for sales). This allows each member of the team to focus on their personal case filter instead of periodically picking from a filter that’s shared by the entire team.

Send & Close

When we reply to a customer, we almost always do so using ‘Send & Close,’ which sends the email and then closes the case. This behavior implies that we consider our work done until the customer responds, either because we’ve solved their problem (hopefully) or because the customer needs to provide additional information in order for us to continue troubleshooting. (If you use Send & Close, be sure to make the aforementioned workflow modification).

Separate Inbox Work from Engineering Work

At a small enough scale, it’s manageable to simply fix bugs as they’re reported and immediately respond to the customer that the bug is fixed. As more support emails start coming in, this can quickly become untenable.

Although it may not be obvious, there are actually two distinct work items at play when a customer reports an issue:

1. Respond to the customer
2. Fix the Bug

This applies both for legitimate bugs (e.g. “flagrant error occurred when trying to check email”) as well as issues that merit being fixed two ways (e.g. “based on the error message, customer didn’t realize they didn’t specify their mail server. Easy workaround, but a clearer error message would be helpful”).  When these kinds of emails come into FogBugz, we’ll spawn a new case into the engineering project and put ‘See Case XXXX’ in the description to refer back to the original case.

Sometimes a bug fix is required before responding to the customer. We’ll keep the email case open as a reminder to check in with the engineering team. The engineer can fill their case with ugly stack traces and esoteric notes while the inquiry case remains reserved for communicating with the customer.

Mostly, we simply use “Send & Close” for the inquiry case and the bug case is handled in the development team’s triage process. This means the work of responding to the customer is considered done even if the bug is still open. If the customer responds to check the status of the bug fix, the inquiry case is reopened and a reply is needed per our usual one business day response time.

Other Techniques

We make heavy use of javascript bookmarklets to spawn new cases. The best way to make a new FogBugz bookmarklet is to start with a working bookmarklet and edit it to your liking. For example, you can use this bookmarklet as a starting point.

We recently blogged about the Case Event Merge Plugin, but it’s worth mentioning again here. Since we have “Reply Automatically” turned off, sometimes customers will fire off a separate ‘one more thing…’ email that creates a new distinct case, thus two (or more) cases for the same email thread. The Case Event Merge Plugin allows us to resolve the duplicate case and have all of the separate emails show up in the original case, essentially collapsing the conversation into a single thread.

In the bottom left corner of our cases, we show a ‘mini search’ that tries to match the case correspondent with our internal customer database. This is a simple iframe embedded via a BugMonkey script and it saves us lots of time looking up customer information.

Conclusion

While we have a lot of tiny little hacks to get email just right, all of them are relatively easy to implement. Your workflow is probably different from ours, but hopefully you’ve found something that you can apply to your environment to improve email support. The key point is to be fearless when it comes to changing and customizing FogBugz to meet your needs.

If you have any additional questions about how we implement our support workflow, don’t hesitate to send us an email.

The default workflow in FogBugz is pretty simple:

1. Assign a case to someone.
2. When they resolve the case, it gets assigned back to you.
3. Verify & Close the case or Reactivate it.
4. Rinse and repeat.

You can customize the default workflow using the Workflow Plugin, which will let you change the person who gets assigned a case for a particular status. However, sometimes you want to be able to move a case between various steps, e.g.

Dev  →  QA  →  Production

We wanted to make it easier for FogBugz users to visualize this kind of linear workflow, so we wrote a simple BugMonkey script that shows you the workflow at the top of the case and gives you a button to click to go directly to the next step. Here’s a quick video walkthrough:

This is a really simple way to add workflow to your cases and shows how powerful BugMonkey can be to customize FogBugz. Get the script and add it to FogBugz via My Settings > Customizations.

This video is only about fun and has nothing to do with any of our products. Enjoy!

A few weeks ago, Betsy Weber of TechSmith (the folks who make SnagIt and Camtasia, among other things) sent us a box full of toys, including sporks, Rubik’s cubes, and kits to make our own BrushBots. What’s a BrushBot?

Toothbrush + Vibrating Pager Motor + Battery = BrushBot

One Friday afternoon, a few of us gathered in the lunch room and had fun putting them together. Check out the video:

When we launched Trello last year, we immediately heard from customers that they wanted Trello integration with FogBugz. It’s a reasonable request:

Fog Creek made FogBugz.

Fog Creek made Trello.

Fog Creek should make them play nicely together.

So over lunch, I asked one of the FogBugz developers, “Why haven’t you made a Trello Plugin yet?” And he responded, “We would love to make a FogBugz plugin that integrates with Trello! What do you want to see?”

I drew a blank.

The solution wasn’t immediately obvious to me and I couldn’t think of a good design off the top of my head—certainly there is a good solution; it just wasn’t obvious to me what it should be. There are a billion different ways you might present FogBugz data in Trello. Plus, Trello is still maturing and (currently) lacks web hooks. Both of these things make integration with FogBugz a bit challenging at the moment.

There’s not a FogBugz-Trello integration plugin yet, but several customers expressed an interest, and I was sure I could help them out. We recently talked to a FogBugz customer who uses multiple Active statuses in their workflow and uses Milestones to break up sprints. Something like this:

Given their workflow, their request seemed pretty reasonable. For a given project:

• FogBugz Milestones as Trello Boards
• FogBugz Active Statuses as Trello Lists
• FogBugz Cases as Trello Cards, with a link back to the original case.

I decided to use the FogBugz XML API and the Trello API to see if we could make that view possible. Turns out it’s not that hard and this is what you get as a result:

Each card even has a little Kiwi icon that you can click to go right to the case in FogBugz (On Demand only). The script only updates one way (FogBugz => Trello), but I think it’s a nice visualization for this particular workflow. You can get the script here: Milestones to Trello.

Of course, you should modify the script to fit your needs. Would you prefer to see Projects as Boards with Milestones as Lists? Areas as Lists? Edit the script any way you like, and if you come up with something you want to share, send us an email and we’ll add it to our FogBugz recipes.

Do you have an idea for how FogBugz and Trello should play together? Let us know what’d you like to see by leaving an answer on our Trello Integration post.

We have a variety of methods for tracking what features our users are looking for, and by every measurement available, the ability to Merge Cases was at the top of the list! In fact, this has been a top feature request for quite some time.

We’ve had our eyes on this feature for a while now and even drafted a feature specification for it, but while we were drafting ideas, a user from the FogBugz Developer Community contacted us with a fully functional plugin that solved the problem! So, without further ado, may I present the Case Event Merge Plugin, written and generously shared by the developers at Quarantainenet:

“The FogBugz Case Event Merge plugin adds the functionality to display the case events of a duplicate case in the original case…. We have tried to overcome the design problem of merging by not merging at all: we just display the events of one case in the history of the other, keeping the workflow of cases intact.”

Here’s a quick video that goes over how it works:

The Case Event Merge Plugin is available for both FogBugz On Demand and customers running FogBugz on their own server. Follow the installation instructions to get started, and check out the full documentation to see what the authors have to say about it. Read on for a bit of history on the development of this plugin.

Why was this feature so hard to add?

After Quarantainenet knocked the ball out of the park with this plugin, it is easy to look at it and wonder why Fog Creek didn’t deliver it earlier. The answer lies in the details, or to be more accurate, the lack of details.

The solution that Quarantainenet devised is simple because it does not manipulate the existing rows in the database. In the feature specification draft that we were working on at FogCreek for merging cases, we were looking at it from the opposite perspective and dealing with the repercussions of trying to move the bug events from one case to the other within the database. In this scenario we had a lot of corner cases and questions that weren’t trivial to deal with.

For example:

• Once a case is merged to another, does the system delete it?
• What happens with new incoming emails that have the case number for the now-closed duplicate case?
• Do we try to merge the attributes of the two cases together?
• How do you seamlessly transition the conversation to the new case and discourage updates to the old one?

Each of these questions has valid possible solutions that we considered, but would lock the users into a specific workflow, which was something we were trying to avoid. The ability to merge cases had to make life easier for users who kept getting emails with the Case keyword stripped from it, or those infamous CC chains that seem to spawn an endless number of new cases. The solutions we were batting around made life easier in about eight out of ten scenarios, but made life a lot more confusing in those last two cases. The net gain was teetering on the edge of positive, which meant producing it just wasn’t worthwhile.

A Fresh Approach

The genius of the Case Event Merge Plugin is that the only data it requires is a marker for the duplicate cases whose events we want to display in the other case. The real work comes when FogBugz goes to render a case view page; the plugin interacts with the rendering process and creates a bunch of “pseudo bug events” from the duplicate cases. (The Kiln plugin uses the same pseudo bug event mechanism to show changesets inline with the rest of the case). These events are read from the database just as they would be if the user went to view the closed duplicate case. What this means is that the Plugin can crash, fail, be deleted, mucked with and otherwise abused and your original data is left completely intact.

Because Quarantainenet was never thinking about manipulating the existing Bug and BugEvent tables, their solution exclusively utilizes the rendering of the case view. This means that all of the core FogBugz code gets to keep chugging happily along, completely oblivious to the fact that these two cases are anything but “Resolved as Duplicates”! It’s simple, elegant, and it just works.

This plugin is already being used heavily at Fog Creek and we know many of our customers are excited about its release as well. Several years after the feature request first appeared, we’re glad that we can finally mark it as Resolved (Implemented).

If you’re using FogBugz On Demand, we’re already regularly backing up your database. However, we do occasionally bring the system down for periodic maintenance, and one of our customers wanted to know how they could maintain a local copy of their important FogBugz data just in case our services were unavailable. They didn’t necessarily want the database itself, but just a way to look at case data in a pinch.

While we never plan downtime during your productive work hours, we can empathize with always wanting a local copy—just in case—in order to stay productive (for your source code, we of course offer a distributed version control solution, which promises exactly that).

To solve this problem, we added a simple script called ‘Backup FogBugz’ to the recipes section of the FogBugz XML API Development wiki. It checks FogBugz for unread cases, then saves the updated case info to a local HTML file. It doesn’t save everything—you wouldn’t be able to e.g. restore FogBugz with this data—but it does give you a relatively fresh copy of the data on your local machine.

Here’s a quick video overview of how it works:

Within Kiln, you have the ability to control who can access your code via project and repository permissions. This feature has been around since Kiln’s early days, but I thought it might be a good idea to put together a quick video to show how you can use permissions to enhance your existing DVCS workflow. If you want to learn more about Kiln workflows, check out a recording of a recent Hg Init Webinar.