This page describes record action security and how to configure it.
Tip: If you're new to configuring security on your record type, see Security in Appian Records to learn how the different security configurations impact a user's ability to see your enterprise data.
Appian makes it simple to secure your enterprise data at a granular level when you use record-level security to specify who can see which records. But records are more than just a row of data—they're a combination of data, record views, and record actions.
Using record action security, you can further secure your records by determining who can see your record actions and when.
By default, any user can see a record list action if they have Initiator permission to the underlying process model. For related actions, a user must be able to see the record and have Initiator permission to the underlying process model.
To ensure that only the right users can take action on the right data, you can conditionally show or hide record actions.
Let's examine these options by considering a support case application used by support engineers and their supervisors. The Support Case record type has record actions for New Case, Update Case, and Delete Case, as well as a bulk edit record action used to update multiple cases at once. Record action security lets the right user add or change support case information based on no-code rules.
The New Case and Update Case actions use the default settings: any user with Initiator permission to the Create or Update Case process model can make a new Case record. If that user can see a specific record, they will also be able to update it. The delete action will be restricted to users who created the support case or their supervisor.
Supervisors have exclusive access to the bulk edit record action. When a supervisor views the record list, they can see all of the Case record actions.
To show or hide actions (like Update Case) so they're only visible to the right users, you can configure one of the following options:
Note: In the latest version of Appian, existing Visibility expressions configured on your record actions are now called Security Expressions.
When you enable data sync on your record type, you can configure easy-to-maintain security rules on your record actions.
Similar to security rules configured in record-level security, security rules configured on your record actions allow you to translate your complex security requirements into plain language. You only need to answer two questions: who can see this action? and when can they see this action?
The first element of a security rule determines who can see the action.
By default, any user with Initiator permission to the underlying process model can see a record list action. For related actions, a user must be able to see the record and have Initiator permission to the underlying process model.
Your security rule allows you to further limit who can see an action to only users found in specific groups or fields.
With the Only users found in groups option, you can further limit the action to users found in any of the groups you specify.
For example, in a Customer record type, you may have a related action called Create Payment Plan, and you only want the finance department to see this action.
To configure this security requirement, you can add a security rule so the Create Payment Plan record action so only users found in the Finance Department group can see the action.
By adding this security rule, a user will only see the Create Payment Plan action if:
Tip: If a group doesn't exist yet, you can create a new group directly from the security rule. Simply click to create a new group and use it in your security rule.
With the Only users found in fields option, you can further limit the action to users found in any of the User or Group fields you specify.
For example, on the Case record type, you may have a related action called Review Refund for supervisors to approve or reject a refund. Because this action has financial impact, you only want supervisors to be able to complete this action.
To configure this security requirement, you can create a security rule on the Refund action so only users found in the supervisor
field can see the action.
By adding this security rule, a user will now only see the Review Refund action if:
supervisor
field.
Tip: This example uses a record type relationship with the User record type to find the employee's supervisor. Selecting the assignedEmployee
field from the User record type is similar to using the loggedInUser()
function to determine who is looking at the record action.
You can combine the Only users found in groups and Only users found in fields options. Appian checks if the user meets any specified condition, so a user can see the record action if they are found either in a group or in a field.
For example, in an Employee record type, you may have a Edit Performance Review action. You want only the employee's manager or Human Resources to see this action.
To configure this security requirement, you can specify that a user can see the action when they meet the following conditions:
username
field, or the supervisor
field.
Tip: This example uses a record type relationship with the User record type so that the employee can edit their own performance review. Selecting the username
field from the User record type is similar to using the loggedInUser()
function to determine who is looking at the record action.
Once you determine who can see the record action, you can add security conditions to specify when they can see the action.
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 on the record type.
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 when a field in the Only users found in fields option and the fields used in your security conditions use the same one-to-many relationship.
For example, on the Customer record type, say you have an Delete Order action to cancel newly submitted orders. You only want the case to be deleted by the person assigned to the order when the case's status is "Submitted" and its priority is not "High".
The security rule configuration would look something like this:
Since the fields used in the When can they see this action? section are all from the same one-to-many relationship, the AND_ALL
operator will be applied so that only users who meet all of the security conditions can see the action.
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 selected 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.
You can only add a security rule to a record action if your record type has data sync enabled. If your record type does not have data sync enabled, you must configure a security expression to secure your record actions instead.
To add a security rule:
Select Only users… to specify that only users who have access to the underlying process model and are found in specific groups or fields can see the record action.
If you want to... | Then... |
---|---|
Add users from a group |
|
Add users from a field |
|
Add users from a group or field |
|
After you configure and save a security rule on a record action, you can edit it at any time.
To edit a security rule:
In addition to record action security, you can specify the underlying process model's security directly from the record type.
Users must have Initiator permission to see a record action, so this allows you to quickly update any security settings as necessary.
To edit a process model's security:
While security rules allow you to configure most of your security requirements, you may choose to use a security expression if you need to describe more complex security conditions, or if your record type does not have data sync enabled. Where you configure and maintain your security expression changes depending on whether your record type has data sync enabled.
A security expression allows you to show or hide the record action from certain users based on the conditions you specify in the expression. A user can only see a record action if the security expression evaluates to true for that user.
For example, in the Employee record type, you may have a Promote Employee action that changes the employees rank to the next level. However, you only want Human Resources to see this action and only under the following conditions:
Since this example requires users not to be included in a group, you could create a security expression on the Promote Employee record action that looks something like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
if(
and(
rule!getTenure(loggedInUser()) >= 1,
not(
a!isUserMemberOfGroup(
username: loggedInUser(),
groups: cons!PERFORMANCE_IMPROVEMENT_GROUP
)
),
rv!record[recordType!Employee.relationships.promoChecklist.approved] = true
),
true,
false
)
To add a security expression on a record action when your record type has data sync enabled:
To add a security expression on a record action when your record type does not have data sync enabled:
If you decide that you'd rather maintain your record action security using a security rule, you can replace your security expression with a security rule at any time. You can only perform these steps on a record type with data sync enabled.
To replace a security expression with a security rule:
Record Action Security