Blog 

We've now got most of the Workflow tables defined, but we are still missing a few things. One of those things is a definition for exactly who can perform Transitions; we're going to add SubjectToAcl att to the transition model and use nopCommerce AclRecord table for our Security

In previous post, we showed what Customers can do to Entities, and this post we will show what happens to the Customers as a result.

Having already defined our Workflow Infrastructure, and our StateTypes and Transitions, we can now start to design models for what a User can actually perform to an Entity in this engine. Let's start by creating Actions.

Now that we've got the Workwlow model created, we can start building models for the actual process itself. In this part, we'll design the models that will hold the different States an Entity can be in as part of a Workflow, and we'll also design the tables that show how to get from one State to another (which are called Transitions). First, though, we need a table that shows what different types of States can exist. Let's get started!

Before we can design anything else in this Workflow Engine, we first need to define what exactly makes a Workflow.

Our company was developed CMS plugin to simplify process of creating new entities for nopCommerce. We are using this plugin extremely in our development process and it’s really good solution for creating new pages and templates for nopCommerce. Also we started to use it for implementing Business logic and noticed that a lot of processes were relatively similar: Our company started thinking that, since we had so many similar processes like approvals and notifications, could we build a database-driven tool to manage all of them?