Record Type Object Security

When you create a new record type, you're prompted to configure the record type object's security. Like any other object, a record type's security is made up of groups and role maps to determine who can see and modify the record type and its properties.

Object-level security is the broadest layer of security on a record type. For more granular control over who can see specific records, fields, views, and actions, see additional layers of security.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Record type object permissions

If you generated groups and folders when you created your application, the record type role map will have the following permissions by default:

• App Preview Administrators group has Administrator permission.
• App Prefix Users group has Viewer permission.
• Default (All Other Users) has no access.

If you did not generate groups and folders, then only the record type creator and system administrators will have access to the record type by default.

The following table outlines the actions that can be performed by each permission level in a record type's security role map:

Actions	Administrator	Editor	Viewer	Data Steward
View the record type in a site, Tempo, and as a dataset in Process HQ*	Yes	Yes	Yes	No
View the record type	Yes	Yes	Yes	No
View the object security	Yes	Yes	Yes	No
Update record-level security	Yes	Yes	No	No
Update the record type	Yes	Yes	No	No
Update the object security	Yes	No	No	No
Delete the record type	Yes	No	No	No
Use this record type in a process in Process HQ	No	No	No	Yes

^* Additional workspace settings are required.

Additional layers of record type security

Object-level security is only the first layer of security you configure on a record type. It determines who can access the record type itself, but you can define more granular security by applying additional layers:

• Record-level security: Determines who can see which records. For example, support engineers can only see their assigned cases, while administrators can see all cases.
• Field-level security: Determines who can see which fields. For example, you can hide salary information from users who don't need to see it.
• Record view security: Determines who can see specific record views. For example, you can restrict a financial details view to managers only.
• Record action security: Determines who can see and use specific record actions. For example, you can restrict a delete action to administrators only.

Each layer builds on the previous one. A user must first have at least Viewer permissions on the record type object before any of the more granular security layers apply.

Related record type security

When you add a relationship to your record type, Appian enforces the object security and any record-level security configured on the related record type. If a user does not have sufficient permissions on the related record type, references to those related record fields return null.

How related record type security is enforced depends on the context:

• Queries, expressions, and components: Related record type security is applied automatically. You do not need to add extra filters to protect sensitive data.
• Security rules using Users who can view related records: Related record type security is applied. The security rule grants access only if the user can view the related record.
• Security rules using Users found in fields: Related record type security is not applied. The security rule checks whether the user is stored in the specified field by traversing the relationship path directly, regardless of the security rules defined on the related record type.

If your security requirements depend on the related record type's security being enforced during evaluation, use Users who can view related records instead of Users found in fields.

Secure supporting data source objects

Depending on the record type's data source and data access method, you may need additional objects to connect and access the data source. In addition to the record type security, you must also have permissions to the objects that connect to your data source.

The following table outlines the different objects you need to secure based on your data source and data access method:

Data source	Data access method	Additional objects to secure
Database	Optimized data access	None
Database	Direct data access (features enabled)	None
Database	Direct data access (features disabled)	Data store
Web service	Optimized data access	None
Web service	Direct data access (features disabled)	Connected system, Integration object, Record data source expression rule
Process model	Direct data access (features disabled)	Process model

Feedback