Workflow Bundle Philosophy and Design?

[StephenOTT]

Hey sorry to bother you with more questions. Just trying to get a handle for some of the more complex configurations in the platform.

Looking through the code and docs for the Workflow bundle...

Is there any design and philosophy thinking you can share for how the workflow bundle was built? Why Transitions are where the "work" is done, and steps are the "status" / positioning in the workflow?

I am comparing to something such as BPM / BPMN (http://www.bpmn.org) (http://bpmn.io) where the Task/Step is where the work is done, and the transition is the movement to another step/decision made to move to another step. Another example that comes to mind is LogicPull: https://logicpull.com/tour

More questions to come about workflow, but wanted to start with this.

[mbessolov]

Using traditional BPMN terminology, an Oro workflow transition is quite close to the BPMN "Activity" definition.
The reason why transitions are not called "activities" is that they are not limited to a standard set of four BPMN Activity types ("Task", "Sub-process", "Transaction", "Call Activity") and also include their "Connections" and allow for "Gateway" configuration (forking and merging).

OroPlatform Workflow is focused on the customer needs (including ability to provide, extend and modify workflows by 3-rd party developers and/or system integrators), usability and the user experience in general. Conformance to a specific standard may be achieved by creating an integration to a desired BPMN tool (most of which unfortunately use non-interoperable formats and APIs).

BPMN 2.0 standard does not have a "Step" definition, this is just another term crafted by mere mortals who cannot parse the overwhelmingly complex BPMN specification.

[StephenOTT]

ha ha 👍 very nice description @mbessolov 😄

What was the reasoning for having transitions as where "work is done" rather than in steps? and having the current implementation of steps (more of a "Status") become a type of Step?
Why I ask is the confusion i am continually having when looking at the workflow diagrams and logic... When you draw a workflow on a whiteboard or in a diagramming app, you use Boxes/Steps/Tasks/Activities to represent work, and lines/transitions to represent flow.

Also noticing that under the Transition's Attribute, you select white fields to be available for edit. Was longer term thinking that custom forms could be used?

[mbessolov]

And just for clarification, by "non-interoperable" formats I meant primarily that there is no agreement between BPMS (business-process modelling software) vendors on how some things should be represented. The examples most common in B2B/B2C worlds (including commerce and CRM) are queues for sales teams or customer support, and handling of messages.

[StephenOTT]

And just for clarification, by "non-interoperable" formats I meant primarily that there is no agreement between BPMS (business-process modelling software) vendors on how some things should be represented. The examples most common in B2B/B2C worlds (including commerce and CRM) are queues for sales teams or customer support, and handling of messages.

Agreed. I see the newer CMMN (http://www.omg.org/spec/CMMN/) (Case Management Model and Notation) as being BPMN's solution to that problem. https://camunda.org has a pretty good initial implementation of this.

[mbessolov]

I recommend to check the Workflow bundle built-in documentation - Configuration Reference or Getting Started. Not all the functionality that is available to developers is represented in the UI yet.

An OroPlatform workflow transition is not a line. On a BPMN diagram it would most likely be represented as a box with the lines connecting this box to other object on the diagrams, as well as possibly some "diamonds" before this box.

[StephenOTT]

I recommend to check the Workflow bundle built-in documentation

Ya thats what i have been going through. Just been using the UI to see how you guys were thinking of representing this stuff 😄

What I am trying to understand is the logic (not saying it's wrong, just want to get the mental model in my head) of using Transitions to activate the Form that the user uses to modify data rather than have this done in the Step and use the transition to evaluate which step should occur next.

[mbessolov]

If it helps a Step represents a state (same meaning of state as in state diagram or non-deterministic finite state machine ) of some entity for the workflow purposes. This "workflow purposes" state of an entity includes the state of the entity data (basically values of its fields) and state of the corresponding workflow item object (which is used to capture the state that cannot or should not be stored in the entity fields). If states are represented as vertices on a state diagram, then workflow transitions are exactly what state diagram transitions are - directed graph edges between some states (vertices).

[StephenOTT]

If it helps a Step represents a state (same meaning of state as in state diagram or non-deterministic finite state machine )

State Diagram as the model you followed clarifies it for me. So then my question is Why was workflow bundle developed around State Machine / State Diagrams rather than the more traditional/common flowchart? (https://en.wikipedia.org/wiki/State_diagram#State_diagrams_versus_flowcharts) ('A' being a state flow and 'B' is flowchart:

In the past I have mainly seen state implemented as a "snapshot" in time similar to "Change History" of a entity, where each version can have a label representing the state.

Is there benefits to the State Diagram over the flowchart that you wanted to leverage?

[StephenOTT]

@mbessolov also noticing that (at least through the UI) that only one workflow can be associated and active for a entity. if you activate a second workflow, this disables the previous workflow. Is there doc that talks about this? Cant find it if it does exist.

Why I ask is based on #394 (comment) and #394 (comment) it seems like it is better to think about the Workflow Bundle as an Entity State Machine rather than a 'workflow' tool. Is that the way to look at it?

[mbessolov]

There is no single "better" way to think about the Workflow Bundle.
Different individuals might find different mental models more or less suitable for them based on their experience or education. Not every major requires learning what state diagrams or flowcharts are, and actually users should not be required to get a degree or become BPMN experts in order to configure the system behavior to match their business needs.

[StephenOTT]

Was not comparing to BPMN at this point. Was just thinking of it as the typical "workflow" experience is centred around flowchart rather than State Diagram. Soon as you explained it was State Diagram oriented, the confusion was eliminated because was no longer trying to associate it with other workflow implementations that are flowchart oriented. 😄
The Oasis Workflow Wordpress plugin (https://en-ca.wordpress.org/plugins/oasis-workflow/screenshots/) is a example flowchart rather than the State Diagram:

Where the Step is equivalent to the WorkflowBundle's Transition, and Result is the WorkflowBundle's Step.

Edit: Fixed typos

[DimaSoroka]

@StephenOTT, we also have documentation available on our website, feel free to contribute.

To summarize the discussion above current implementation of workflow represents a state machine around an entity and allow to define steps in your workflow and transition rules between steps. In case you need to have multiple entities involved in the workflow, you can introduce a custom entity that will have relation to other ones and will have workflow associated to it (Sales Process is an example of such case in OroCRM). We are going to improve user and developer experience for such case so multiple workflows could be associated with entity(s) without a need to create some additional one.

[StephenOTT]

@StephenOTT, we also have documentation available on our website, feel free to contribute.

Did not think to look in the Oro Book for the workflow explanation. I was looking through the Bundle docs. My Bad!

I will look to update book and bundle docs with suggestion for note about workflow being oriented around State Diagram rather than flowchart.

Thanks @DimaSoroka and @mbessolov !!