Well I came across such a challenge a couple of months back. The scenario was - our organization was building an HR application which needed to have workflows that were 100% configurable (not with the end user but with the support team - no change of code). There were a number of actors involved and the workflows had to be defined according to the paths a specific request could take depending on certain parameters. At the same time, this model had to be generic enough to be used across all other modules (e.g. Travel, Leaves, Performance etc.)
We evaluated the Sharepoint point but did not find it entirely suitable enough so chose to move to a table based Dynamic Workflow. The model had 2 main parts -
1) Workflow : This part consisted of 2 main tables, the first one to define the workflow (the name, remarks and a unique business key that could be used in the configuration file of the .NET application to link it). The second one contained the steps for each of the workflow defined in the first table. Each of the step had an action (e.g. Approved, Rejected, Cancelled) and actor (e.g. Business leader, HR manager, Director) associated with it and the next step (self-referencing). This table was actually just an implementation of a forward only linked list. The last steps in the chain had the next step pointing to NULL and a couple of flags were kept to track the first and the last steps in the workflow.
2) Approvers : This was the hard part. Approvers had to be defined using a dynamic list of parameters that could be applicable in parts depending on the role. The approvers were managed with 3 tables.
Keeping the workflow and approvers in completely separate entities with only a soft link between them enabled us to produce a very adaptable structure.