Record Permissions Fields
Record permissions fields to control user access at the record level. For example, in a Vendor Profiles application you can give all vendor relationship managers access at the application level, and then use a record permissions field to ensure that vendor relationship managers can only see records of the vendors with which they work.
If a user has access to an application that contains a Record Permissions field, that user will only be able to view records for which he or she has been selected in that field. All other records in the application will be completely hidden from the user. Users can be granted access to a record through a Record Permissions field if the user’s name is selected in the field or if 1 of the user’s groups has been selected in the field.
On this page
Permission models
Record permissions fields provide 3 permissioning models for granting record-level access to users and groups.
Manual permissions model
This model allows your users to select users and groups in the field. You define which users or groups are available for selection in the field, and you define the level of record access that should be granted to that user or group.
By default, all users and groups selected in a record permissions field have read access to their assigned records. However, you can also grant update and delete privileges. You can also define rules that control the level of permissions the selected users and groups receive based on record content.
Inherited permissions model
This model means that the field inherits record permissions from related levels or applications and displays as a read-only field to your users. The value of the field is automatically populated by 1 or more record permissions fields that you define.
For example, say you have a Vendor Profiles application that cross-references your Contracts and Assessments applications. Vendor relationship managers need access to records in all 3 applications for the vendors they work with. You can create inherited record permissions fields in the Contracts and Assessments applications that inherit permissions from a manual record permissions field in the Vendor Profile application, so that when a vendor relationship manager is assigned to a vendor profile, that user also gains access to the related contracts and assessments.
Inherited record permissions fields can either be unrestricted, where the field inherits permissions from all related records, or restricted, where the field inherits permissions only from specific records.
If you have existing records in the application that you are managing, a process is triggered to set permissions for those records. If you delete a parent-level record with child-level records that inherit permissions from that parent, the permissions in the child-level records are deleted.
Important: Inherited record permissions fields are not tracked in a history log field. If a history log field is configured to track the record permissions field before it was changed to use inherited permissions, the record permissions field is removed from the history log configuration, and all data for the field is deleted. Further changes to the record permissions field values are not tracked in the history log.
After you select the inherited permissions model for a record permissions field, you cannot change the permission model.
Automatic permissions model
This model assigns record-level access automatically based on data conditions in the record, using 1 or more rules that you define, and appears as a read-only field to your users.
After defining 1 or more conditions for rule fulfillment, select the users and groups who have access to records in which the specified conditions are met. When selecting users and groups, you can also specify whether those users and groups have read-only access to their assigned records or whether they have update and delete access.
For example, you could create a rule in a Document Repository application that assigns full record-level access to the Documentation group when the Document Status is Draft. You could define another rule that assigns read-only record access to the Everyone group when Document Status is Final.
When using the rule-driven selection method, you must also select 1 or more default users or groups who have access to records in which none of the rules are met. You can also specify whether those users and groups have read-only access to their assigned records or whether they have update and delete access.
How record permissions fields work with other elements
|
Element |
Rules |
|---|---|
|
Calculations |
Record permissions fields are not recalculated in archived applications or questionnaires. In a forced recalculation of a record permissions field, users must have update permissions to perform the recalculation. Recalculation conditions for inherited record permission field values
The recalculation occurs only if the available users or groups are changed for a manual selection record permissions field or if the rules are changed for an automatic selection record permissions field. Permissions are recalculated for individual records each time a value changes that causes a new rule to prove true. In addition, record permissions are recalculated for the entire application if any 1 of the following occurs:
|
|
Conditional Layout Actions |
For record permissions fields that are selected for inclusion or exclusion in an ACL action, only the data committed in the database determines whether a user is included or excluded from the ACL action. Only the data committed in the database determines whether an ACL action is applied to the specified user. Any user that is selected in a record permissions field is excluded if the field is excluded. An Apply Conditional Layout (ACL) action does not give users added field permissions, but it can restrict them.
|
|
Data Feed |
Record permissions are evaluated and may limit the source data retrieved from the application. |
|
Data Imports |
Record Permissions fields must be configured with the manual permissions model. When an empty value is imported into a Record Permissions field, the field is empty in the new or updated record regardless of whether the field is configured with 1 or more default values. When no value is selected in the Record Permissions field, only users who are a system administrator or content administrator can access the record. |
|
Notifications |
Record Permissions fields cannot be included in the subject line of the notification. For Scheduled Report Distributions, the content of an attached report is based on the record permissions of the user who creates the report. A dynamic recipient list is based on the values of a record permissions or an email address stored in a field. Recipients can only view records for which they have record permissions. Only a record being saved runs Generate Notification actions in a data-driven event. This action runs at the end of the record save process and is the only action that runs after calculated fields and record permission fields are computed. Once a rule is applied to a Record Permissions field, the field becomes calculated. When the calculation triggers a permission change, Archer counts the change as a change to the record. The record change then triggers a notification. |
|
Packaging |
User/Groups field population may be added to Record Permissions fields, but the packaging installation does not remove the existing ones. If a User/Groups field in the target instance is configured as a Record Permissions field in the package, the package installation changes the field to the Record Permissions type. When installing a package that contains Record Permissions fields, verify that users and groups already exist in the target instance. If they do not, these fields may not install properly. If necessary, create the users and groups in the target instance before installing the package. |
|
Questionnaires and Campaigns |
Record permissions fields are not recalculated in an archived questionnaire. A target application must have a User/Groups list or Record Permission field before you can assign a submitter or reviewer for each questionnaire record triggered by a campaign. By default, questionnaires include 2 User/Groups List fields: Submitter and Reviewer. These fields facilitate a 2-stage workflow process. You can define the users and groups available for selection in these fields, and you can promote the fields to Record Permissions fields if you want to use them to control access to questionnaire records. In addition, you can add User/Groups List or Record Permissions fields to expand the content review process according to your risk management methodologies. |
|
Search and Reporting |
User/Groups list and Record Permissions fields, which normally display as a link to the profile page when populated, do not display as links when Inline Edit is enabled,. If an application contains a Record Permissions field, users can only access the fields to which they have permissions in the application. |
|
Workflows |
Record permissions apply for records in the workflow process. All users with proper access privileges can view a record in the workflow process. Only users that have been assigned a record in the workflow process can accept or reject it. |
