_This is Part 6 of an eight-part series describing how to design a database for a Workflow Engine. _Click here for Part 1
We’ve now got most of the Process tables defined, but we are still missing a few things.
One of those things is a definition for exactly who can perform Actions or receive Activities; we’re going to call this Targets.
The second piece we need is Groups, or collections of people that perform a similar or related job in this process. In our design, we want to allow for a Group to also be a Target. Let’s see how we can design these tables!
Groups
A Group is a collection of Users that perform related functions.
For example, we might have a group called Programmers that actually write code, or a group called Executives that approve projects for development. Because we are building a generic Workflow Engine, we want to make sure that each Process can have its own Groups.
The Group table is pretty simple:
We also need a table to represent which Users are in a given group, which will be another many-to-many table. This table is called GroupMember:
Targets
Remember that this system is people-focused; only people can action the Request. We still need a way to associate which persons (or Groups) can perform Actions and receive Activities.
The problem is that we may need to specify that only the Requester of a given Request can send that request to his/her supervisor, or that all of this set of people need to receive an email when a Request reaches a certain State. How can we design this in such a manner that it is flexible in who can perform the Action or receive the Activity, but still implements a few rules that the engine must follow?
We can accomplish this by creating Targets. A Target is a set of standardized representations of a person who have specific roles relative to a Request or Process. We use the following targets:
- Request Creator (Requester)
- Request Stakeholders
- Group Members
- Process Admins
Our Target table looks like this:
Because this is another static table (like StateType, ActionType, and ActivityType), we don’t expect the data in it to ever change. Here’s the data we will be using for this design:
#workflow engine #database
