As we mentioned in the previous section, extending the CMS workflow is all about state management. However, it's impossible to manage state if you can't "see" events as they fire. To solve this problem, CMS has several workflow events that are fired at various times in the workflow process. You extend the CMS workflow by adding business-specific logic to the appropriate event or events.
CMS workflow events are "fired" at various times in the workflow process. Each event is really an event pair one event in the pair fires before a state change occurs, and one fires after. All events that fire before the state change end with "ing." All events that fire after a state change end in "ed." To make things a little more interesting, any given state change may involve one or more event pairs. In fact, there are always at least two event pairs firing for every posting state change, but there may be more.
In Table 31-2, we've provided a list of the standard workflow events and a brief description of when they fire.
To help you better understand how events fire, let's look at one example. In Figure 31-1, we show the flow of an event firing sequence for an approval action on an existing posting. As we described earlier, you can see how the "ing" event fires first and then the "ed" event fires. Also, you can see that there are actually two pairs of events in the sequence. CMS will always fire the Changing and Changed events regardless of what action is taken; in reality, the Changing and Changed events may fire more than once for certain workflow actions.
Figure 31-1. The event firing order for an approval action
When you're extending the CMS workflow, it's likely that you don't need to catch all events, just the specific ones that are germane to your process. Further, adding code to multiple events may have unexpected results if you're not careful.