# Conditional Permissions {% hint style="info" %} **Premium feature** Conditional Permissions is a premium feature. Availability is determined by your subscription. Please check your current subscription or contact customer success to ensure you have access to this functionality. {% endhint %} Conditional Permissions are configured as part of the [Object Class Permissions](https://docs.appfarm.io/reference/security/permissions/..#object-classes). Object Class Permissions serve as the maximum permission a given Role may have towards a given Object Class (create, read, update or delete). With Conditional Permissions, you may grant conditional access for different Roles to different Object Classes, and it is an important concept when defining [data silos](https://docs.appfarm.io/how-to/data-modeling/data-silos) for a multi-tenant application. As with normal Object Class Permissions, the Conditional Permissions are enforced server side (back end) and are tamper-proof as opposed to hiding data or UI using conditions inside your App. {% hint style="info" %} **Good to know** If your Solution relies heavily on Conditional Permissions, you might benefit from Data Aggregation Service. Conditional Permissions rely on aggregations, and this add-on provides access to specialized database infrastructure that caters exclusively to aggregation workloads. Read more in our [Product Glossary](https://policies.appfarm.io/glossary/product-glossary#data-aggregation-service). {% endhint %} {% tabs %} {% tab title="Example" %} The Role `End Users` have `Read` and `Update` permissions towards the `Person` Object Class, for users to update their own `Person` object from a view in an App. However, on a permissions level on the back end, all `End Users` have access to *all* `Person` objects - not only their own record/object. Without Conditional Permissions, you must be very strict with filters and what data to load into your App. With Conditional Permission, you may set up a rule that is enabled for End Users, only allowing you to read and update your own `Person` object. {% endtab %} {% endtabs %} ## Setup Guide This is a short guide on how to set up Conditional Permissions given a specific use case. ### Use Case Consider the following Data Model

A logged-in `User` has an `Person` object. A `Person` belongs to a `Company` and may have a set of `Person Documents`. A `Company` may have a set of `Orders`. We want to make sure 1. The user only has read access to the `Person` object (the one connected to the Current User) and the belonging `Person Documents` 2. The user only has access to the connected `Company` and the belonging `Orders` ### Configuration For configuration of Conditional Permissions, go to **Security** -> **Permissions** -> **Object Classes.**

Configuration of Conditional Permissions

#### Read-permissions on the Person Object Class Clicking the Filter icon for the `Person` Object Class in the above screenshot opens a dialog for configuring the conditional Read-permissions for the Person Object Class.

* **Name**: Optional, this is just a describing name for the rule * **Enabled**: This is where you set the condition on when this rule should apply. In this example, this rule should only apply when the logged-in user has the Role `End user` * **Filter**: The filter that always should be applied when reading Persons (enabled when ). In this case, always apply the filter `Person.User = Current User`. Note that when Read permission has been set up conditionally for a given Role (or Roles), and some other Roles should have access to all, we need to add a rule for that as well. In the below screenshot, any user with a membership in any of the Roles `Owner`, `Maintainer` or `Developers` has read access to all `Persons`.

In other words: With Conditional Permissions set up, a user will get the sum of permissions defined by the rules in the setup above. If a user is both a `Maintainer` and an `End User`, the user will have read access to all `Persons`. #### Read-permissions on the Person Documents Object Class The same Enabled conditions and set of rules apply to this Object Class. But the Filter is different.

We need to define the path from `Person Document` to `Current User`, for the Read-permissions to work. The above screenshots illustrate how to set up a filter on *all Person Documents belonging to a Person that the Current User is connected to*. #### Read permissions on the Company Object Class For these permissions, we need to define a filter on all *Companies belonging to the Person that the Current User is connected to*.

In the above screenshot, the `Person` Object Class has the following filter:

#### Read permissions on the Order Object Class For these permissions, we need to define a filter for *all Orders belonging to the Companies of the Person object that the Current User is connected to*. It is the same setup as for the `Company` permissions, except the left side of the filter (where `Order.Company` is the property we are filtering on).