Do domain model xpath constraints apply to microflows?

I was simply wondering if a retrieve activity in a microflow is always constraint by that what has been set in the domain model? Let's say I have two entities in my domain model: Teacher,  Group. As a teacher, I want to be able to only see the groups I have been assigned to. In such case, I make a domain model xpath constraint limiting Group access to the group I (as a teacher) have an association with. Now if I run a microflow as a teacher that contains a 'retrieve all Group objects', will it return all groups or only the ones that I have an association with?    - - - - For the record: If the answer is "Yes, constraint will apply to the microflow results as well", please elaborate. I just tested this and it is retrieving all groups, not just the associated ones..
2 answers

By default, access rules are not applied for microflow actions. So you can retrieve, delete, change objects, even if you don't have the domain model access, but do have the rights to execute the microflow which does these actions.

So, a retrieve action in a microflow, will retrieve all objects, but if the objects are passed on to a page (for example, if it's a datasource microflow), you will still only see those objects you are allowed to see.

But, for example, if you don't have delete permissions in the domain model, but you do have permission to a microflow, which has a delete action, you are allowed to delete an object.

Another example: if you do a retrieve, and then a delete action, you can delete all objects, not only those for which you have domain model rights.

If you want to ensure domain model access rules are applied in microflows, you can set the option 'Apply entity access' to yes.


Then, the domain model constraints will be applied.

See the documentation for more info:



By default, microflows have the option 'Apply Entity Access' set to 'false' (also recognizable by the white background in your microflow). This means that no access rules set in the Domain Model are not applied. This is easy because otherwise any microflow triggered by a normal user would never be able to reach any data that, even though they aren't allowed to read it themselves, might affect the flow of the microflow.

This is usually the best option for most microflows, as a user can trigger a microflow that does all sorts of actions in the background that you would not want the user to be able to directly do, but triggering the microflow is a legitimate call, usually supported by validation rules and checks. This way, the microflow is the only way for the user to trigger for example the creation of special back-end objects with specific values. While they won't be able to create these objects themselves through say the Mendix JavaScript API or using datagrid create/edit buttons, the microflow will do this for them by bypassing the entity access within a controlled environment.

If you want, you can turn on 'Apply Entity Access' in order to apply the domain model entity access rules in that specific microflow. This will turn the background of your microflow a faint yellow.