How do cases move through FogBugz?
The basic statuses in FogBugz come in two flavors, Active and Resolved. By default, there is only one active status for each type of case, but if you need more active statuses, like Needing Replication to your instance, you can do so via Admin > Workflow
Resolved statuses differ per category. A bug will be marked Resolved (Won't Fix) whereas a feature will be resolved Resolved (Won't Implement). Again, you can customize this via the Workflow admin menu.
The basic workflow of FogBugz is that cases are created in projects, assigned to the default assignee for that project, remain active until fixed, and then are resolved back to the person who created the bug, who is responsible for verifying its resolution and closing the case.
This doesn't always fit the workflow of software organizations, where you might want a QA person to test. For this, you can set the default assignee for, say, the Bug status of Resolved (Fixed) to QA, while the default assignee for Resolved (Won't Fix) should stay as the opener of the case.
The Force option in the Workflow plug-in simply means that the assignee cannot be changed in the same step as the resolution. In keeping with FogBugz's general design principles, the assignee can be changed immediately after the forced step.
FogBugz allows for basically two steps of automated workflow: Active and Resolved. For more complex organizations, it is possible to set up scripts and customizations to approximate a case moving through multiple steps (legal, accounting, executive review, PR). But it's really not what the tool was designed for. For such complex and changeable processes, it's generally the better choice to use something more geared toward complex workflow (and likely much, much more expensive) or something more flexible like Trello.