Hi there “Process Automation” fans,
Welcome to a new installment of “Process Automation” tips.
I create and implement lifecycles for OPA now for about 7 years. Some simple, some advanced…The more advanced they get, the quicker you hit the wall of limitations of the way you want to implement something; But is it really a limitation? Or do we just follow what was taught to us without exploring beyond. Well, learning the basics is one thing…Watching the pros is another thing! So, keep on reading and be amazed “what else” is possible from a lifecycle standpoint.
Let’s get right into it…
You know the drill, boot up your VM, and dive into your favorite project. I have a simple ‘Case’ entity available where we add a new ‘Lifecycle’ building:
The implementation for a lifecycle “normally” starts with something like this:
So, that’s moving from one state to another when all activities within the state are completed. You can change it to a conditional transition like this and moving from stage to another one:
You can even do things like this:
That multi-final-state-construct is valid; Although I also hear/see different!? Let me know what you’re thinking in the comments below.
All nice and great, but if you want to move conditional-wise within the state from activity to activity? You can only connect with Automatic, Manual, or Intermediate; Read about them here.
Right…So, what about nested states? Yes, what about them?…Well, you can’t do things like this:
Neither is this:
Hmmmmm…So, what is the “golden nugget” here? As I want to stay into my current state and move from activity to activity! Why staying in the state? Well, that’s for the primary transition path of the lifecycle panel on an entity layout…”Aha”-moment!
…
Watch this implementation:
The beauty of this implementation is that you (or better the “knowledge worker”) decides the routing based on property conditions he/she sets on the entity instance (in our case, the ‘Case’ entity). This makes your lifecycle much cleaner, simpler, and easy to read. You (as low-code developer) are even a little more in control how the flow moves from A-Z.
With this approach, you can even move from one sub-state to another sub-state:
Niceee…we’re learning stuff here! 🤠 BUT beware that the lifecycle isn’t going to be a spiderweb of overlapping flows and nested states. Always keep the simplicity in place for others to collaborate with it. Nobody benefits from an overengineered lifecycle implementation!
That’s a “DONE” with a fascinating way (or is it just logic) of lifecycle implementation. I always thought this was impossible as it “smells” like BPM logic which is not truly “case-centric” development. Only, when the customer requests an implementation like this they get what they ask for with feedback on where we can improve to better highlight the true knowledge worker who can make decisions on the fly and add ad-hoc tasks when needed. This lifecycle model implementation is a hybrid implementation where the knowledge worker still makes the decision to go left or right with static tasks to execute on. It’s an interesting way of thinking…Let me know your thoughts in the comments below, and we see each-other next week in other episode of Process Automation Tips.
Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The Process Automation guy”?
