November 13, 2011 at 12:03 am
If anyone here has created a data model for a successful workflow application I'd like to hear about it.
What were some of the considerations you factored into the design? What were some of your lessons learned?
November 13, 2011 at 9:50 pm
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.
November 13, 2011 at 11:58 pm
If anyone here has created a data model for a successful workflow application I'd like to hear about it.
What were some of the considerations you factored into the design? What were some of your lessons learned?
There are pretty much simple rules for DB designing and they are independent of technology & domain. A workflow application DB should be normalized. Here is something to start-up.
Stairway to Database Design Level 9: Normalization
November 14, 2011 at 1:51 am
saurabh.kaushik (11/13/2011)
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.
Thanks for that info Saurabh. My first workflow datamodel was less dynamic to allow for more db-level constraints. However, now I realize that flexibility and the ability to easily change the workflow definitions are key to a quality workflow data model. In the future I think I'll create workflow data models that revolve around 2 tables: WorkflowRule and WorkflowData....
August 10, 2014 at 8:49 am
Hi Saurabh,
Could you tell, how did you handle conditional workflow steps like moving from step1 to step2 or from step1 to step4(skip step2 and step3) based on data values.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply