Tip: Already familiar with record-level security? Jump to instructions on how to add and manage security rules or a security expression.
Securing your enterprise data is a critical and often difficult experience, especially when you need to control who can see which rows of your data. Configuring this type of row-level security often requires technical leads and data experts to implement and maintain your security logic—but that's not the case with Appian Records. We make it easy to secure your enterprise data at this granular level using record-level security.
You can configure record-level security directly on your record types with data sync enabled. This means you can configure your security more dynamically since you can leverage record fields, groups, constants, and more to define your security logic. Since you're leveraging your synced data, you can also use related record fields in your configurations so you can define your security requirements using data from different systems.
Once you configure your security requirements and save your record type, Appian will automatically and performantly enforce your security anywhere you reference the record type. With record-level security, you can focus on building your interfaces, reports, and queries, while Appian takes care of ensuring users can only see the appropriate data.
The sections below provide more information about record-level security and how to configure your record-level security.
For other security information, see:
Record-level security allows you to specify who can view which records.
By default, any user with Viewer permissions in the record type can see all available records. However, your enterprise may have more strict guidelines around who can see which data.
For example, in a support case application, administrators should be able to see all cases, but support engineers should only see their assigned cases, and account managers should only see cases related to their customers.
To determine which users can see specific records, you can configure record-level security on your record types with data sync enabled.
Record-level security is layered on top of your object security. This means that users must have permission to view the record type and permission to view the records. For example, if an Administrator has Administrator permission for the record type, but is not included in the record-level security, then they will not see any records.
By applying record-level security on top of your object security, you can control security at a more granular level and ensure your data is only visible to the appropriate users.
For example, if you apply record-level security to the support case example above, administrators and support engineers would see different records when looking at the same Case Burndown report.
Records visible to an administrator:
Records visible to a support engineer:
You can configure record-level security on your record types using one of the following options:
Note: If on upgrade your existing record type had a default filter, we'll automatically change it to a security expression. However, you can always switch from a security expression to security rules.
The table below outlines the key differences between these two options:
| Security Rules | Security Expression | |
|---|---|---|
| Configuration | Use a guided experience to specify who can see which records. | Create an expression to specify who should see which records. |
| Inherit security from related record types | You can inherit security rules from related record types, so you only need to maintain the security logic in one place. | You must configure a security expression on each record type. |
| Testing | You can easily test security rules during record type configuration, disabling and enabling rules to see how each configuration impacts the user. | You must log out of your current user, then log in as a different user to test the expression. |
| Performance | Performance is automatically handled by Appian. | You must consider performance when creating your expression. |
Security rules allow you to translate your complex security requirements into plain language by answering two questions: who is a part of this rule? and which records can they view?
The first element of a security rule is defining who is a part of your rule.
In this section, you can specify the users assigned to a security rule by selecting one of the three options:
Let's look at some examples of when you'd use one membership option versus another.
The Users found in groups option allows you to assign users found in one or more groups to your security rule. When you select more than one group, the security rule will be applied to any user who belongs to any of the selected groups.
Consider using this option when you want to assign multiple users to a security rule.
For example, in a support application, you want administrators and executives to be able to see all cases in the Case record type. To configure this security requirement, you can create a security rule that specifies that any users found in the Administrators group or the Executives group can see all cases.
Any time you add new users to your groups, they will be automatically assigned to the security rule.
Tip: If you need more complex group membership conditions (like a user needs to be part of the Administrators and Executives groups), consider using a security expression.
The Users found in fields option assigns any users found in a User or Group field to your security rule.
This provides a more dynamic configuration option since your security requirements are defined by your data. You can select record fields or related record fields in your configuration.
For example, in a support case application, you only want support engineers to view cases that they're assigned to. In the Case record type, you can add a new security rule that specifies that if a user is found in the assignedEngineer field (which is type User), then they can see the case.
With this configuration, support engineers will only ever see their assigned cases. If the data changes, and a support engineer is no longer assigned to a support case, the security rule will automatically reflect your data change so they can no longer see the case.
To learn how to configure a record field as type User or Group, see Change record field names and data types.
The Users who can view related records option assigns any users who can see related records to the security rule. This option leverages your record type relationships so you can extend the existing security rules on a related record type to the base record type.
For example, in a support case application, let's say you only want account managers to view cases related to their customers. The security rules on the Customer record type define which account managers can see which customers. If you select this option on the Case record type, then select the customer relationship, you can extend the Customer security rules to the Case record type.
Now, any user who can view a customer can also see that customer's cases.
If you select a one-to-many relationship in your security rule, then users who can see at least one related record can also see the base record.
For example, let's say you need to extend security rules from the Case record type to the Customer record type. On the Customer record type, you can use this option and select the case relationship so any users who can see at least one case can also see the customer.
With this option, you can avoid recreating security rules across numerous record types by simply inheriting the security rules from a related record type.
Once you've assigned users to the security rule, you can add security conditions to define which records they can view.
Depending on how you assigned users to the security rule, Appian applies certain default security conditions:
| Option | Default Security Condition |
|---|---|
| Users found in groups | None. |
| Users found in fields | Users can only see records where they are found in the specified fields. |
| Users who can view related records | Users can only see records if they have access to view the related records. |
These default conditions are automatically applied and cannot be modified. You can, however, add additional conditions as necessary.
For example, let's say you only want account managers to view customer cases created in the last month.
To configure this security requirement, you would first select the Users who can view related records option so any user who can view a customer can also see their cases. Then, you can add an additional security condition so that those users can only see cases greater than or equal to the beginning of last month.
As shown in the image above, security conditions are made up of fields, operators, and values. Depending on the selected field, your operator and value options will change.
The field picker contains all record fields and relationships defined in the record type. However, depending on how you assigned users to the security rule, the fields available for selection will vary:
| Option | Available fields |
|---|---|
| Users found in groups | All record fields and relationships available from the base record type. |
| Users found in fields | All record fields and relationships available from the base record type. |
| Users who can view related records | Only record fields available on the base record type. |
Note: You cannot use real-time custom record fields that were created with the Aggregate Related Record Fields template or that use the following functions: today(), now(), rand(), timezoneid(), timezone(), or local().
When creating multiple conditions against fields from the same one-to-many relationship, Appian will combine those filters using the AND_ALL operator. This includes the Users found in fields option when the selected field and security conditions are against the same one-to-many relationship.
For example, let's say you only want supported engineers to view a customer if they are assigned to an active case for that customer and that case has a service-level agreement (SLA) status of "On Time."
From the Customer record type, you'd create a new security rule using the Users who can view related records option and select the assignedEngineer field from the Case relationship. Then, you can add two additional security conditions so that assigned engineers can only view those customers when the case is both open and has the correct SLA status.
The operator list displays all of the operators that can be applied to the selected field. Only operators that are compatible with the data type of the chosen field display.
The following tables explains the behavior of each available operator:
| Operator | Description | Applies to data types |
|---|---|---|
= |
Equal to | Text, Integer, Float, Time, Date, Date and Time, Boolean |
<> |
Not equal to | Text, Integer, Float, Time, Date, Date and Time, Boolean |
< |
Less than | Integer, Float, Time, Date, Date and Time |
> |
Greater than | Integer, Float, Time, Date, Date and Time |
<= |
Less than or equal | Integer, Float, Time, Date, Date and Time |
>= |
Greater than or equal | Integer, Float, Time, Date, Date and Time |
in |
Matches a value in a list of values. Only available when using constants. | Text, Integer, Float, Time, Date, Date and Time, Boolean |
not in |
Does not match a value in a list of values. Only available when using constants. | Text, Integer, Float, Time, Date, Date and Time, Boolean |
is null |
Is empty or null | Text, Integer, Float, Time, Date, Date and Time, Boolean |
not null |
Is not empty or null | Text, Integer, Float, Time, Date, Date and Time, Boolean |
You can select how you want to pass in the condition value using the value context menu. The options in the context menu change based on the data type of the selected field. You can enter a static text value, or use a constant to determine the value the field must evaluate to in order for users to view the record.
Note: You must have at least Editor permissions for the record type to add or update security rules.
To add a security rule:
Determine Which records can they view by adding one or more security conditions. Depending on the members you assigned to the security rule, your configuration may differ:
| If you selected… | Then… |
|---|---|
| Users found in groups | Select Only records where… to configure a security condition. |
| Users found in fields | A default security condition is applied where users can only see records where they are listed as the user or group in that field. To add more conditions, click + Add Additional Conditions. |
| Users who can view related records | A default security condition is applied where users can only see records if they can see the related record in the related record type. To add more conditions, click + Add Additional Conditions. |
Click CREATE.
Tip: If you want to add another security rule immediately after creating one, click CREATE AND ADD ANOTHER RULE instead.
Click PREVIEW RECORDS to see a list of records visible to the selected user.
Note: When previewing record data, you can only see records that both you and the selected user have access to view.
Once you create a security rule, you can disable, edit, or delete the rule as needed.
To disable or enable a security rule:
When a security rule is disabled, it will not be evaluated when testing the rules or anywhere throughout the application. If you disable all security rules, any user with Viewer permissions for the record type can view all records.
To edit a security rule:
To delete a security rule:
If you delete all security rules, any user with Viewer permission for the record type can view all records.
Although security rules allow you to configure the majority of use cases, you may choose to configure a security expression if you need to create more complex conditions.
Security expressions allow you to create a series of filter conditions using a!queryFilter() or a!queryLogicalExpression() to define which records are available to users based on the conditions you specify.
Each filter defines a condition that must be true for a record to appear in queries to the record type. If you have multiple conditions, the record must meet all conditions in order to appear.
For example, in a support case application, let’s say you only want users to see all unassigned cases if they are a member of the Support group, and are not currently assigned to a case. Since the membership conditions are more complex, you could configure a security expression on the Case record type that looks something like this:
However, there are two limitations to using a security expression:
This means that you would need to expand your security expression to include all possible users, like account managers and administrators, so they only see the appropriate records. Additionally, related record types like the Customer record type, cannot inherit the security expression.
For easy maintenance, we recommend using security rules on your record types.
Note: You must have at least Editor permissions for the record type to add or update security rules.
To add a security expression:
queryFilter or queryLogicalExpression.Once you define your security expression, you can edit it at any time. Alternatively, if you do not want to continue using a security expression, you can also choose to remove and replace your security expression using security rules.
To edit the security expression:
If you decide that you'd rather maintain your record-level security using security rules, you can remove the security expression and use security rules instead.
To switch from a security expression to security rules:
Record-Level Security
