This section of the Data tab provides security by allowing you to define rules to prevent users from seeing or modifying data they should not have access to. To do this, define rules for each of your custom types, if needed. When multiple rules apply, the user has access to an object if any one rule grants access to it.

This button creates a new rule for the selected type. Name the type with an explicit name and define conditions and permissions. The condition defines which users this rule applies to, while the permissions define what they can do with the data if they meet the conditions.

Name the rule. Modify the name in this input.

Clicking this icon deletes the rule. This action does not delete data. It only removes the rule for the selected type.

Define the conditions that check whether a given user is part of the rule or not. Create a dynamic expression with the Composer, building it piece by piece. For example, if you define the condition for the type 'Event' as 'This event's creator is current user,' then only the user who created the thing of type 'event' will be part of that rule.

This defines what users in that current rule can do with the data.

Uncheck this box to prevent users who are in this rule to see the search results for this type.

Check this box for these users to be able to see all the fields of a thing of the current type, provided they meet the conditions. If you uncheck this box, you will be able to select which fields are viewable by users in this rule.

If this box is unchecked, users will not be able to see the uploaded files attached to a thing of this type. For example, let's say you set up a workflow where users can create an 'Apartment,' and that apartment has pictures. Set up the picture uploader in a way that links the picture to the actual apartment in the database. Then, if you uncheck this box and if the condition is 'This apartment's creator isn't current user,' other users will not be able to see that picture, even if an image displays it or if a user has a link to the image file.

Bind the content of an input to a field of a thing. When the user modifies the content of the input, the thing gets updated automatically. See Enable auto-binding on parent element's thing for input elements. You need to enable users to modify fields through a permission. Use 'Allow auto-binding.' Check this box to allow users to do this if they meet a condition. Once checked, choose from the different fields that can be modified through auto-binding.

When the Data API is enabled for this type, this permission grants the user the right to modify any of the fields of this thing. For the modification to be allowed, the rule that governs this permission must be true both before and after the modification. This lets you restrict which fields may be modified. If you need more granular field restrictions, instead of granting this permission, use the Workflow API, which lets you control exactly what gets changed.

When the Data API is enabled for this type, this permission grants the user the right to delete this thing via the API.

When the Data API is enabled for this type, this permission grants the user the right to create new things via the API. If the rule that grants this permission references fields on the thing, attempts to create a thing where the rule does not apply will be rejected.

If you have an element that displays data only to certain users, that data could be briefly displayed to a user that does not have permissions if this user triggers a workflow that you as a developer have defined to modify that piece of private data and if the modification does not need to come from the server or a remote source such as an external API.

Fortunately, we have a feature for this use case. See Scheduled Workflows.