Before writing any code, a little planning to map your business process to SharePoint workflow can go a long way. The two most important things to keep in mind are that
A)SharePoint workflows areDocument-centric, Meaning they run process around a document or list item, and
B) they are human-based , meaning that they can drive people process by assigning tasks, in addition to automated computational process.
How do these things help? well, knowing the capabilities and strengths of SharePoint workflow can help you plan the structure of the workflow's surrounding SharePoint objects, what the workflow shocould do, and how it can get the information that it needs. for example, since a workflow instance runs on an item, you have access to the content and fi ELDS on that item; do you want the workflow to manipulate metadata, and if so, what columns do you need ?
If you're designing a workflow That doesn' t really "process" or route a single document, e.g. A workflow that involves reviewing a set of tickets instead of just one, wocould it work to use items that link to those documents ENTs in a regularList instead of a document libraryAs starting points for the workflow?
If you need to drive people to do different tasks,Where and when shocould tasks be assigned, AndWhat data do you need to collectFrom those people when they complete their tasks?
Also,Workflows run as SYSTEM account(Administrator privileges) so that it can do things that ordinary people cannot, like creating audit entries.Can you take advantage of this for any part of the process?
Once you have a sense of what your workflow needs to do, you can start the authoring process.
In the next entry, I'll be starting the five steps in developing workflows. :) next: Step 1: model your workflow in