Advise customer on separating security and business entities

content/en/docs/quickstarts/native-mobile-app.md

@@ -58,7 +58,7 @@ In the pop-up window that appears, enter a **name** for your app. Leave all othe
 Just as in part one, we will need to create the entity to store employee data. In the **domain model** for the Native Mobile Module, add a **new entity**.
 
 1. Name the entity Employee.
-1. The entity should be a generalization of the Account entity.
+1. The entity should be a specialization of the Account entity.
 1. Add three attributes to the entity:
     * FirstName as String
     * LastName as String

content/en/docs/refguide/modeling/domain-model/entities/access-rules.md

@@ -94,7 +94,11 @@ To edit the XPath constraint, click **Edit...** next to the XPath constraint fie
 XPath constraints can only be applied to persistable entities, as they are applied by the database. Defining XPath constraints for non-persistable entities results in consistency errors.
 {{% /alert %}}
 
-There are two constraints that can be appended easily with a single button click:
+{{% alert color="info" %}}
+The **Owner** and **Path to user...** buttons described below are not available in the XPath **Builder**. You have to switch to entering an **XPath expression**.
+{{% /alert %}}
+
+There are two constraints that can be appended with a single button click:
 
 ##### Owner
 
@@ -106,22 +110,22 @@ The **Owner** button adds an XPath constraint so the access rule is only applied
 
 This constraint is only valid when the [Store 'owner'](/refguide/entities/#store-owner) checkbox in the **System members** section of the entity properties is checked.
 
-##### Path to User
+##### Path to User {#path-to-user}
 
 The **Path to user...** button adds an XPath constraint so the access rule is only applied when a `User` object which is associated (directly or indirectly) with the current object is the current end-user. When you click **Path to user...**, you can select a path to an associated entity that is either a `System.User` or a specialization of `System.User`. This is then converted into an XPath constraint for the access rule.
 
-For example:
+Take, for example a customer visiting a webshop:
 
-1. Assume that the **Customer** entity is a specialization of the **User** entity. The **Order** entity is associated with the **Customer** entity via the **Order_Customer** association.
-2. Assume that a logged-in customer is only allowed to view their orders, but is not allowed to view the orders of other customers.
+1. Assume that the `Customer` entity contains information about an individual and is associated with the `Administration.Account` entity (which is a specialization of the `User` entity) via the `Customer_Account` association. The `Order` entity is associated with the `Customer` entity via the `Order_Customer` association.
+2. The customer can sign in to the webshop app using the linked Administration.Account, but is only allowed to view their own orders. They cannot view the orders of other customers.
 
-The XPath constraint can be constructed easily using the **Path to user...** button by selecting the **Customer** entity in the **Order** entity access rule. The created rule will look like this:
+The required XPath constraint can be constructed using the **Path to user...** button on the `Order` entity by navigating to the `Administration.Account` entity via the `Order_Customer` and `Customer_Account` associations in the entity navigation tree. The created rule will look like this:
 
 ```xpath
-[Module.Order_Customer = '[%CurrentUser%]']
+[Module.Order_Customer/Module.Customer/Module.Customer_Account='[%CurrentUser%]']
 ```
 
-Because of this XPath constraint, access defined in the access rule is only applied to orders for which the customer is the current end-user.
+This XPath constraint means the current end-user can only see orders for the customer associated with the current end-user.
 
 #### Entity Rights
 

content/en/docs/refguide/modeling/security/app-security/administrator.md

@@ -72,15 +72,15 @@ The user role assigned to the Administrator. For more information, see [User Rol
 Default: *Administrator*
 
 {{% alert color="info" %}}
-The administrator is always created and has the System.Administrator role by default. The System.Administrator role allows users of your application to be managed. 
+The Administrator user role is always created and has the System.Administrator module role by default. The Administrator user role can also manage users of your application as it has all [manageable roles](/refguide/user-roles/#user-management). 
 
-For Free Apps, the user that created the application automatically has this role by default as well so you can use it to manage your users in that environment.
+For Free Apps, the user that created the application automatically also defaults to having the Administrator role so they can use it to manage the users in that environment.
 
-This role may be helpful in case you have exceeded your user license restriction in which case you can use any user that has this System.Administrator role to sign in to manage your users.
+This role may be helpful if you exceed your user license restriction, as you can sign in as any end-user that has this Administrator user role to manage your end-users.
 {{% /alert %}}
 
 {{% alert color="warning" %}}
-When your app is not deployed locally, for example to Mendix Cloud, changes to the user role of the administrator account will not be applied until the administrator password is changed. See the [actions](/developerportal/deploy/environments-details/#actions) section of *Environment Detail* for instructions on changing the admin password.
+When your app is not deployed locally, for example, if it is deployed to Mendix Cloud, changes to the user role of the Administrator account will not be applied until the Administrator password is changed. See the [actions](/developerportal/deploy/environments-details/#actions) section of *Environment Detail* for instructions on changing the admin password.
 {{% /alert %}}
 
 ## Read More

content/en/docs/refguide/modeling/security/app-security/anonymous-users.md

@@ -21,8 +21,12 @@ The properties of anonymous users are described in the table below:
 | Allow anonymous users | When **Yes** is selected, anonymous users are allowed. End-users do not have to sign in to access the application. <br />When **No** is selected, anonymous users are not allowed. End-users have to sign in to access the application. |
 | Anonymous user role   | The user role that end-users of your application have when they are not signed in. This tells the application which role should be automatically applied to anonymous users who access the app. The **Allow anonymous users** property should be set to **Yes** to select an anonymous user role. |
 
+{{% alert color="info" %}}
+Mendix advises always naming a user role which allows anonymous users in an app or module as `Anonymous`. This ensures that it is clear to all users what it is being used for. 
+{{% /alert %}}
+
 {{% alert color="warning" %}}
-Enabling anonymous users allows anyone to use your app without signing in. To prevent unintended data exposure, ensure that the anonymous user role has limited access across your app by configuring appropriate entity and microflow access rules.
+Enabling anonymous users allows anyone to use your app without signing in. To prevent unintended data exposure, ensure that the anonymous user role has limited access across your app by configuring appropriate entity and microflow access rules. See [Configuring User Roles and Access](/howto/security/best-practices-security/#access-control) in *Implement Best Practices for App Security* for more advice on configuring user roles.
 {{% /alert %}}
 
 ## Read More

content/en/docs/refguide/modeling/security/app-security/user-roles.md

@@ -83,7 +83,7 @@ If the **Select / deselect all** box is checked (that is, all roles are manageab
 {{% /alert %}}
 
 {{% alert color="info" %}}
-Internally, user management properties are translated into implicit entity access rules for **System.User**. This means that they are not applied in microflows that do not check entity access.
+Internally, user management properties are translated into implicit entity access rules for **System.User**. These implicit rules are not applied when a microflow runs with [Apply entity access](/refguide/microflow/#security) enabled as only explicitly configured entity access rules are checked.
 {{% /alert %}}
 
 ### What Can User Roles Manage?