It would be my first time to implement BPT in OutSystems. Previously, we are used to drive the workflow via Policy which makes it more dynamic. I know that BPT has good capabilities on its own but the fact that you are coding the flow only means that it would be hard for catering complex workflows.
Anyone already had the same problem or any ideas making a dynamic workflow but still using BPT?
I'm not into dynamic workflows but did you check if the available api's for processes (processes api and BPT api)
? Maybe they can help you somehow.
Say I have a scenario for a Bank Customer Support. The whole process or workflow is like 10 steps: e.g. step 1 is registration, step 2 is upload documents, step 3 review document, etc.
For customers calling for credit approval, say we need only steps 1,2,3,5,6,9,10.
And then for customers that just want to update their personal details, you only need steps 1 and 10.
Plus, should they want to create a whole new process where I can do all steps 1-10, I can do it on the fly (since the workflow logic is already there) by creating a new policy for it.
For the scenario, we created a policy which drives what workflow that is needed based on the type of request or inquiry. Such cases, based only on what I saw on the Modelling Business Processes, I think it would be hard to implement such only with it. Unless I am not just aware there is a way to do it or rather an approach that caters the use case.
Thanks for your explanation!
Natively, I think you can't do it with OutSystems but it is something that you should suggest in the Ideas page to be developed. I would vote for that.
Alternatively, at design time you can design a Process and insert a lot of If's and Decision's nodes but, depending on the quantity, it would like messy and not maintainable code. At runtime I'm afraid you can't change the process.
I'm no expert, but maybe this will help.
You could try and crete separate business processes for each of your steps. These are called from your "main" processes as you can see in this picture:
If you want for processes to adapt dynamically to a (changing?) ("policy"?) state, then the main process would call all steps in sequence, and each step could make its own checks like this:
The "PolicyCheck" decision could make its check from a row on your entities, making this as dynamic as you need. However, if a process is waiting for user input, it won't re-check this row and will therefore not "automatically shape-shift" to another "policy". This would occur only when a new step is run.
How much "shape-shifting" do you really need?
PS: You can actually set a Human Activity to close automatically when a certain entity is updated (say the entity that stores your state/policy).
You can also add an "On Close" event action which would then check if the change requires the Human Action to really close or not, and if not, abort the close.
This might still require further decision nodes on the process that includes the Human Activity, so the overall complexity really depends on how flexible you want your business process to be.
But it's doable the way you need it.
Thanks Pedro for the detailed explanation complete with the visuals :D
Anyways, here what I am thinking. Say I have setup policies like below:
Now based on the 'steps' the workflow policy have, I will then compare in BPT if the steps are present or not.
I just didn't complete the flow but I know you get the point. This way, even if I create a new Workflow Policy record, it will still just flow into this BPT logic and do the necessary checks and processes. Your thoughts?
i would suggest the ff:
i hope that i have assisted with your Inquiry.
If you intention is to launch a process as policy X and that instance of the process doesn't change policy until it ends, then your solution with decision nodes, as also suggested by Thomas and then by me, would work.
Caveat: if you "Terminate" (rather than normally end) a sub-process (Step01, Step02, etc.), only that sub-process will be terminated, not the parent process.
Cy's solution might also work -- I don't know if I understood it correctly.
Use whichever solution you understand better to ensure faster, error-free, development.
Hi JC, Pedro, and Thomas,
Good discussion. Let me ask a question and add a few thoughts.
In general, having a parent process call sub-processes that contain the activities that do real work will allow the process to be dynamic as you have described.
Question: Is there a need/requirement for the parent process to select the steps/sub-processes dynamically?
In your examples there are 2 processes and 10 available steps. In reality, I'm guessing there are quite a few processes sharing these 10 steps, but for now let's focus on those 2. Credit Approval and Update Customer Profile each use some of the 10 available steps, but vary as needed for their specific purposes. Would it be a problem to create a "parent" process for each one that just calls the steps (sub-processes) needed?
If 2 processes named Credit Approval and Update Customer Profile are created then you could track and get reports on those individual processes using the Business Activity Monitor application.
If there is just one generic parent process that dynamically chooses the steps, the monitoring of that parent process will be less informative as there are really multiple different processes running in it and they are monitored together.
If the "parent" processes are fairly stable processes, they won't change too often and wouldn't cause too much extra maintenance.
That is one of the trade-offs here. When the processes change they need to be redeployed, but we get a few benefits for that. We get clear, informative monitoring, easier debugging and troubleshooting, and the potential benefit of being able to share the process flow diagram on the web or in documentation because the process becomes human readable.
Your original question is a really good one. Is there a good dividing line between policy and process? I'm not sure there is a single way to answer it. Policies can drive things in a very rule-based dynamic way and processes tend to be more structured and stable, but we can also use them together. There are a lot options and this has gotten too long already, so I'll stop here.
Hopefully this was more helpful than confusing.
Thanks for your input Scott.
Based on the discussion, basically it would just boil down to the specific needs of the customer albeit the Pros and Cons of the two approach. Thanks for noting the effect versus the reporting (BAM) for having dynamic processes I thought of.
Follow-up question though, say I pursued my approach above, that is instead do the reporting versus the Policy (e.g. Average SLA, pending approvals) and just use BPT for the 'taskbox'. Is that a poor (or dumb) way to do it?
Agreed. Making the choice between the 2 approaches depends on the specific situation.
I wouldn't call the policy approach using the BPT taskbox a poor choice or a bad way to do it. It is just a design/architectural trade-off. Doing the reporting against the policy may require a little more work to get the same level of information, but it can be done.
Using the policy approach allows you to be more dynamic and even load new processes as long as they don't need any new steps. You just need to be careful and have a good way of naming and identifying the different instances that get started by the "parent" process.
Personally I would probably use BPT without the dynamic side, but that's just because I have more experience with that approach.
Would love to hear about how it goes and be able to gain some insight about the approach.