To begin, let's do a quick review of the workflow native to CMS for new content; since we covered workflow earlier, we won't do that here in depth we just want to refresh your memory.
CMS provides a basic three-step workflow process for new content. The process starts when an author creates a new posting in CMS, either through the Authoring Connector or through the Web Author. Once the author is finished creating the new posting, they save and submit it for approval. When they submit the posting, it is sent to the editor. Taking the "happy path" approach (ideal case), the editor has two options: accept the posting as is, or make changes and then accept it. Once the editor accepts the new content, the posting is sent to a moderator. Since this is the happy path, we'll also assume the moderator accepts the posting. Once that happens, the posting is "approved." The posting will move to the Published state once the current date and the posting's startpublish date are equal. This basic workflow path is what all postings follow (assuming you have each of these roles defined for your channels).
Now, there are two cases when a posting will not follow the happy path. The first case is when either an editor or a moderator declines the posting. In that case, the posting is "returned" to the author. The second case is when the posting already exists. If the posting isn't new and posting page properties such as startdate name or description don't change, a moderator is not involved in the workflow process; approving a content change to an existing posting only requires editor approval.
So, what does "extending" the workflow mean? Essentially, almost every step we described earlier affects the state of the posting (refer to Table 31-1 for a review of posting states). Every time an action is taken save, submit, approve, decline a posting's state changes; there's a begin state and an end state. For example, when the author creates a new posting and saves it, the state of that posting changes from New to Saved. If they submit a posting for editor approval, the state changes from Saved to WaitingForEditorApproval. Each step in the process only requires one individual in a role (one author to submit, for example) to change the state. Besides the state change, nothing else really happens within CMS. So when we talk about extending the workflow, what we're really doing is governing how the state change occurs and what other operations might need to happen when a posting changes state.
NOTE: In Table 31-1 we qualified the action with a role, since both authors and editors can save, and editors and moderators can accept or decline. Also, there are two posting states that aren't represented here because there is no corresponding workflow event: Published and Expired. If you'd like more detailed information on basic CMS workflow, please refer to Chapter 6.