I’m adding a business process feature to my app and before I start coding, I thought it might be a good idea to vet the design past a few smart yet critical folks.
The basic idea is around the concepts of events and actions. An event might be something like a sale, or attending a seminar, or calling tech support. An action is a scheduled action that someone must perform or check on, or an automated action such as sending a letter.
An event can be manually triggered or automatically triggered by a number of system functions or data points being such as a foreign key being applied (association), a data policy being fired or resolved (the app has a rule-based data policy feature), or a workflow state change (objects within classes can have workflow states). Lastly, another event being fired or resolved can trigger an event.
When an event is fired it schedules a number of automated actions (n) number of days from the event. Actions belong to an object and have a FK to the ActionConfig.
An action can be manually fulfilled or canceled, or it can be automatically fulfilled by another process, or by another association (FK) being applied to the object in question.
| EventTrigger(the things that can trigger the event)
ActionConfig(events that are scheduled)
Action (the actual scheduled events for an object)
The application already has a strong workflow state feature. Every class can have inheritable workflow states with a prescribed workflow state path (A -> B, B -> C, B -> D, C -> D, etc.). If the class has workflow states then the objects must have a workflow state. Workflow State is a part of the association design – think of it as a FK with intelligence. So there’s already some business process flow in the app.
My question to you is, does this look robust enough for scheduling normal business process flow? What am I leaving out? Do the names event and action seem appropriate and obvious? Any other ideas?