This was a fun rabbit hole to go down.
Reviewing the course, I was unable to find a reason for the flow to skip over and approve every record. I recreated it in a lab instance, and encountered the same behavior you've noted. So I began digging...
What I first noted in the test's Execution Details was that the approval field's value was being set to 'cancelled' before being evaluated by the conditions in our flow. So, it was never rejected, leading it to be approved every time. I also noticed that on the record being tested, our approvals were being set to "No longer required." Weird, right?
So, to confirm that was *the* reason, I added a condition to our Approval = Rejected logic.
And the test executed Approval == Rejected successfully.
So we had our flow working, but why was the flow always ending in a cancelled approval status? It turns out, our Social Media table in the use case extends from the [task] table. And further, it turns out that there is an active business rule in our [task] table called "Moot Approvals Upon Cancellation".
Do you see what I see? This BR was implemented, per its comments, to prevent a recursion error (I think), that caused a customer's approval table to become incredibly wonky. It seems like an extra failsafe put in place to prevent that from occurring. Well, I turned it off, and ran our test again (this time removing my 'cancelled' add-in from the equation).
And hey, look at that, the flow is now in purgatory, as there is neither an accept or reject condition in place for it. In an ideal world, you'd manipulate fields per test case to verify the functionality that you're looking for. You could do this a few different ways, such as manually approving or rejecting the record to push the test along.
But yeah, mystery solved. A secret business rule! And a great lesson on table inheritance, too. I hope this was informative for you as it was for me.
Let me know if you have any questions!
This was a fun rabbit hole to go down.
Reviewing the course, I was unable to find a reason for the flow to skip over and approve every record. I recreated it in a lab instance, and encountered the same behavior you've noted. So I began digging...
What I first noted in the test's Execution Details was that the approval field's value was being set to 'cancelled' before being evaluated by the conditions in our flow. So, it was never rejected, leading it to be approved every time. I also noticed that on the record being tested, our approvals were being set to "No longer required." Weird, right?
So, to confirm that was *the* reason, I added a condition to our Approval = Rejected logic.
And the test executed Approval == Rejected successfully.
So we had our flow working, but why was the flow always ending in a cancelled approval status? It turns out, our Social Media table in the use case extends from the [task] table. And further, it turns out that there is an active business rule in our [task] table called "Moot Approvals Upon Cancellation".
Do you see what I see? This BR was implemented, per its comments, to prevent a recursion error (I think), that caused a customer's approval table to become incredibly wonky. It seems like an extra failsafe put in place to prevent that from occurring. Well, I turned it off, and ran our test again (this time removing my 'cancelled' add-in from the equation).
And hey, look at that, the flow is now in purgatory, as there is neither an accept or reject condition in place for it. In an ideal world, you'd manipulate fields per test case to verify the functionality that you're looking for. You could do this a few different ways, such as manually approving or rejecting the record to push the test along.
But yeah, mystery solved. A secret business rule! And a great lesson on table inheritance, too. I hope this was informative for you as it was for me.
Let me know if you have any questions!
