Business process flows can definitely help guide our application users – they always look nice in the demos, and they easily draw positive feedback. But, it seems, when the BPF is designed to cover multiple entities, there are some quirks there.
Here is the BPF I wanted to create:
There are two entities involved:
- Main Entity
- Stage 1 Entity
Once that simple BPF above is created, here is how it looks like in the user interface while I’m still looking at the Main Entity record::
In order to move that BPF to the next stage, I can create a Stage 1 Entity record, save it, and it’ll be fine.
But what if I made “Start” stage active again?
My BPF would lose that link to the Stage 1 Entity record – I could try moving that process to the next stage at this point, but I would have to create another record:
In order to fix this, I need a lookup from Stage 1 Entity back to the Main entity:
With that new relationship in place, it will also show up in the BPF designer:
That relationship will now be used as a filter for the BPF.
For example, once the lookup is set on the Stage 1 Record:
I will see that Stage 1 Record in the dropdown when trying to navigate to the next stage in the BPF:
Well, let’s say it’s all been set up as per the above, so the BPF is, currently, in the second (“Details”) stage:
What happens if I choose to move that BPF back to the “Start” stage again? It will go back to the previous state – Stage 1 Entity records won’t be in the “process path” anymore:
Looking at the Advanced Find for the “BPF Automation” entity at this point, and it’s obvious that link to the “Stage 1…” record has been removed:
Would not it be great if the BPF kept that relationship somehow instead?
Well, since it does not, it seems this is where we may end up getting more than one “Stage 1 Entity” record for the same BPF if the user decided to create another one. Which is not, necessarily, what we wanted to.
One workaround would be to raise an error when an attempt is made to create another “Stage 1 Entity” record for the same BPF, but how do we do it?
For example, here is how it might work:
- We could create a lookup from the Main Entity to the Stage 1 Entity
- Then, we could use a real-time workflow on create of the Stage 1 Entity record to check if that lookup on the Main Entity had already been populated. In which case we could terminate the workflow and raise an error. If it had not been populated yet, then the workflow could put a value in that lookup and allow the BPF to proceed
- Here is what that lookup would look like in my example:
And the workflow follows below.
Checking the condition (if that new lookup from the Main entity to the Stage 1 Entity has been set):
Terminating the workflow if the condition is met:
Setting the lookup otherwise:
Now if I used the same BPF again, went to the “Details” stage, got “Entity 1 Stage” record created, and went back to the “Start” stage, here is what it would look like:
And, if I tried creating another Stage 1 Record, I’d get an error:
Actually, since Quick Create forms are supported in business process flows, we can make this experience a little better by adding a quick create form for Stage 1 Entity:
- In the example above, our users would get an error message without really leaving “Main Entity” screen.
Is there a better option to handle this scenario? Let me know if you have other suggestions!
We have just been testing similar BPF integration concepts for executing complex logic between BPF Stage transitions. How much can we do moving in/out of stages and ability to set the stage during these transitions under certain conditions, etc.
For your scenario, calling a Workflow on the Start Stage Exit trigger could presumably call a plugin to check for a pre-existing Stage 1 Entity and re-associate it for the next stage. If it did not find one, it would create new Stage 1 Entity and associate it. This is probably a custom code-level workaround that you’re trying to avoid though.
In our case, we’re looking for opportunities to call our generic plug-in that can perform this kind of work, which doesn’t represent so much of a code level work around, so this is an interesting use case in that regard.
Good stuff as always.
Hi Mark. It’s not that we have given up on the plugin options, but this whole navigation between different entities within the same BPF has proven to be more complicated than we thought, so, well, trying to keep reasonable balance between investing too much into that kind of low-level customizations and having things working out of the box (so, in the current “iteration”, we are back to single-entity BPF here… might not be the end of it yet, though:) )