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

All of the infrastructure we’ve built so far has lead to this moment. At long last, we can build the final piece of our schema: the Request Actions table.

Request Actions

So we now have Actions that Users can perform to invoke Transitions. Obviously we can’t allow for any action to be performed against the Request; only the actions we need should be allowed.

The Table

Let’s look at the schema of the RequestActions table first, and then show how it would actually be used:

Those last two columns (IsActive and IsComplete) are very important to the actual execution of this table.

Here’s how we’re going to use this table.

1. When a Request enters a State, we get all outgoing Transitions from that state. For each Action in those Transitions, we add an entry in RequestAction, with each entry having IsActive = 1 and IsCompleted = 0.
2. A User may submit an Action at any time. Each submitted Action consists of an ActionType, a RequestID, and a UserID.
3. When an Action is submitted, we check the RequestActions for the specified Request. If the submitted Action matches one of the active RequestActions (where IsActive = 1), we set that entry’s IsActive = 0 and IsCompleted = 1.
4. After marking the submitted Action as completed, we check all Actions for that Transition in that Request. If all RequestActions are marked as Completed, then we disable all remaining actions (by setting IsActive = 0, e.g. all actions for Transitions that were not matched).

#workflow engine #database