I would like to change my application for the Settings object's Before Commit to check if the Default Role contains permissions that are not allowed, at which point it gives a validation message and returns false on the Before Commit. (My Settings object has a 0 - 1 relation with the Role object which has a 0 - N relation with Applications with a 0 -N to Permissions) Problem now is that my running application has a invalid Default Role selected already but I can't change this as my BCo action uses a retrieve from database to get all the permissions connected to the Role associated with the Settings object. This means it doesn't use the newly inputted information I am trying to store and always returns false. Will I need to re-do my BCo action now to use Retrieve from Association multiple times (Sadly retrieve from Association only goes 1 level deep) with multiple iterators just to make sure it doesn't have that one Permission that I'm trying to block? Or are there better options? Or doesn't Retrieve from Association use the new data either? (Or is there no clean way and do I need to disable it, deploy to my server, change the Settings object, save it, re-enable the validation and redeploy it?)
Robert van 't Hof
You're right about using retrieve action by association at your before commit microflow (i.e. it's not sure the object exists in the database or not).
Perhaps you could use three retrieve actions from association to get 3 deep.
First, you could retrieve the Role object by the Settings-Role association from association.
Secondly, you can retrieve the Applications list by the Role-Applications association from association.
Finally, you can retrieve the Permission objects by the Application-Permission association from association.