_This is Part 5 of an eight-part series describing how to design a database for a Workflow Engine. _Click here for Part 1

Having already defined our Process Infrastructure, our Request structure, and our States and Transitions, we can now start to design tables for what a User can actually do to a Request in this engine. For that, we will be defining two terms:

• Actions: Things a user can perform on a Request.
• Activities: Things that result from a Request moving to a particular State or following a particular Transition.

Let’s start by creating Actions and Action Types.

Actions

Actions are things a user can perform upon a Request.

Say we’ve got a request to build a new grocery store, and that request includes the address of the development where it should be built. The person who is in charge of approving new store construction, John, takes a look at the request and decides that, yeah, it’s a good idea to build a store here. He submits an Approval to the Request, which can cause the Request to go to the next state. John has submitted an Action.

Since we don’t want to allow an infinite number of kinds of actions that can be performed, we are going to group Actions together via an ActionType table that looks like this:

Just like the StateType table, this table is independent of the Process and will be considered static. For our database, we’ll use the following Action Types:

Why are we using these action types?

• Approve: The actioner is suggesting that the request should move to the next state.
• Deny: The actioner is suggesting that the request should move to the previous state.
• Cancel: The actioner is suggesting that the request should move to the Cancelled state in the process.
• Restart: The actioner suggesting that the request be moved back to the Start state in the process.
• Resolve: The actioner is suggesting that the request be moved all the way to the Completed state.

The reason we say the person is “suggesting” that the request be moved is that we want to allow for a process to require multiple Actions to invoke a Transition. It is possible that a request will need multiple things to happen before it can continue in the process, and we want to allow for that scenario.

Now we need the table for the Actions themselves. Actions are unique to Processes, and each have an ActionType, so our table will look like this:

Our design for ActionTypes and Actions looks like this:

#workflow engine #database