Atlassian's support workflow (see workflow XML) has evolved over years to meet our needs.
The main flow is Open → Atlassian Investigating ↔ Waiting for Customer → Resolved → Closed.
Besides this main sequence, the following "features" are implemented:
Issue timeouts
If a customer does not respond to an issue for a week, it is automatically (see Automating issue timeouts) moved to Inactivated. After another week's inactivity it is Closed.
If a customer requests some time (eg. to make local investigations), the issue can be Frozen. A frozen issue will be automatically closed after 3 weeks.
Escalation
Customers can signal that they wish to "Escalate" the issue (escalate its priority). This takes the issue through statuses Escalation Requested and Escalated, before returning to the normal workflow. How an "escalation" is interpreted is left up to the company - the workflow just provides statuses to track the request.
Inter-office transfers
Atlassian has multiple offices (currently Sydney, Malaysia, San Francisco and Prague), and we sometimes wish to indicate that responsibility for an issue should pass to another office. This is possible with the Transferred status.
In general, the virtue of having explicit statuses rather than flags on the issue (for things like "transferred") is that we can fire "events" (triggering an email or IM) on them. This is also the reason we have an "Add comments for Atlassian" workflow action looping back to its original status - it provides a hook to fire an event.
Here is an automatically generated diagram of the workflow (generated by graphviz - see the source). The text in brackets is the permissions required to make that transition. Only people with that permission will see the transition link in the web interface.
