Best Practices for Extending Workflow

As with any development activity, there are some guiding principles for extending the CMS workflow. We have provided a few that we had to learn the hard way.

Know What You're Doing

If you change posting properties during a workflow process, make sure you know what you're doing. This sounds like a simple piece of advice, but experience has shown that even if you think you know what you're doing, you still may be surprised by the result. Here are two examples.

• Making changes to objects in the workflow events may initiate the firing of an event. For example, if you change the name of a Posting object, it will fire the PostingPropertyChanging and PostingPropertyChanged event. Improperly implementing property changes causes a PublishingEventRecursiveHandlerException. Refer to the CMS 2002 documentation for the best practice when you are implementing property changes inside a workflow event.

• Certain properties are tied to certain roles, which may adversely impact the flow of a posting. For example, all content is the responsibility of the editor. If, during the workflow process, you change the value of a placeholder, for example, you could inadvertently change the state of a posting. If you change the value during the Submit event, you could revert the posting to a Saved state. Although this is inconvenient for the author and the editor, it's easily solved by resubmitting the posting programmatically; the site will remain unaffected. However, if you change a page property like the startdate, you've now effectively removed the posting from the production site, if it's an existing posting. The reason is that the page properties are not versioned, and page property changes require moderator approval before the posting can be published.

Limit Notifications

Don't overdo notification. E-mail notifications are a nice feature to have. In fact, it's probably the most commonly implemented extension to the workflow (a code sample is provided in the Microsoft documentation). However, as you saw, a workflow event may fire more than once for a single operation. As a result, if you're not paying attention, you could inadvertently send multiple e-mail messages for the same action. Taking this a step further, consider a situation where you have tens or hundreds of authors and somewhat fewer editors. If you have an e-mail sent out for every submission, an e-mail could potentially be sent to every editor responsible for that channel (remember, roles are assigned per channel, and therefore events that fire notifications would only affect the groups assigned to that channel). The amount of e-mail generated from one author's activities is manageable. E-mail from the activities of even 20 authors may be overwhelming. Try creating some very specific business rules that govern how e-mail is sent, or provide a feature to allow editors to turn off e-mail notifications if they so desire. Alternatively, consider providing notifications through some other mechanism, such as tasks in Outlook. You'll still have to manage the volume, but tasks aren't as intrusive as e-mails.

Wait for a While

Consider making no changes to the standard workflow process until you've had CMS in production for a while. It may sound counterintuitive, but you may find that "requirements" for workflow that business users initially communicated during the requirements phase aren't entirely accurate. Given the work involved in coding extensions to workflow, you should allow the system to run without extensions for some period of time. This will allow your business users to become accustomed to the tool and help you better understand how the users really work.