With Atomic Security for Objects, you can secure object fields, actions, object controls, and relationships by individual lifecycle states or assigned roles on an object record. This grants permissions on specific fields, actions, or relationships based on user roles on the record and state of the record.
To configure Atomic Security, you must first assign an object lifecycle to the specified object. Atomic Security settings do not apply to users with a Vault Owner security profile.
Note: Atomic Security is also available for documents. See Configuring Atomic Security for Documents.
Atomic Security for Object Types
Vault applies the same Atomic Security settings on fields or actions across all object types. You cannot apply Atomic Security for specific object types. For example, when setting the state behavior to Read for the Audit End Date on the Campaign object, Vault sets that same permission across all object types for the Audit End Date field. Though Vault displays a list of values for fields or actions that are relevant to a specific object type, this is for filtering purposes only.
Configuring Atomic Security on Fields
Atomic Security on fields allows you to configure field-level security that varies by lifecycle state and role. Atomic Security controls which fields are editable, read-only, or hidden for object records in a given state.
You can also use Atomic Security to define a default state behavior. If the object has record-level security enabled (through matching or custom sharing rules), the default state behavior applies to all roles within that state. You can define overrides for certain application roles.
For example, in VeePharm’s eTMF vault, the Milestone object uses the Draft, Baseline, Planned, and Complete lifecycle states. For most users, the Actual Start and Finish date fields are irrelevant in the Draft and Baseline states and are read-only in the Planned and Complete lifecycle states. To prevent users from seeing those fields, Gladys, a VeePharm System Admin, configures Atomic Security on the Actual Start and Finish date fields. With her configuration, these fields remain hidden while the records are in Draft and Baseline states, and become read-only in Planned and Complete states. Gladys configures an override on the Planned state, which provides Edit access to the Actual Start and Finish date fields for the Study Manager role.
Behavior Options
When setting a default and override behavior, you see the following options:
- Edit: Allows a user to view the field label and edit the field value. This assumes the user has Edit permission on the object records at the security profile level, and the object record is editable (Dynamic Access Control).
- Read: Allows a user to view the field label and value, but not edit the value. For example, a user can see the Therapeutic Area field on a Product record, but cannot update the value.
- Hide: The field value is never visible. When editing a record, the field label also does not appear.
How to Set Atomic Security on Fields
To set Atomic Security on fields:
- Navigate to Admin > Configuration > Object Lifecycles. Click into a lifecycle and then into an individual state.
- From the Atomic Security: Fields section, click Edit.
- Select Edit (default), Read, or Hide from the State Behavior picklist to apply the security setting to each field.
- Optional: Click + Role Override to add an Application Role to override the state behavior. This option adds the selected role to the page. You can then select a different behavior for each action.
- Click Save to make the changes effective.
When creating a new object record, Vault does not assign a lifecycle state and role to the record. However, security settings configured on the entry state and owner role override, if defined, are automatically applied when creating a record.
Limitations
- Users can still search for field values hidden with Atomic Security using VQL or faceted search in the user interface. Search results will not display the field value, but a user may determine more or less accurately the value by conducting multiple searches and observing whether or not object record appears in the results. Hiding a field with Atomic Security does not prevent a user with malicious intent from guessing hidden field values.
- Audit trails, displayed in the Actions menus on the object details page, do not honor Atomic Security. When hiding fields with Atomic Security, we recommend disabling the Object Record Audit permission to prevent users from seeing hidden field values.
Configuring Atomic Security for Object Controls
With Atomic Security on object controls, you can granularly control whether users can see certain UI elements of an object’s layout based on lifecycle state and role.
How to Set Atomic Security on Object Controls
To set Atomic Security on fields:
- Navigate to Admin > Configuration > Object Lifecycles. Click into a lifecycle and then into an individual state.
- From the Atomic Security: Controls section, click Edit.
- Select Read (default) or Hide from the State Behavior picklist to apply the security setting to each control.
- Optional: Click + Role Override to add an Application Role to override the state behavior. This option adds the selected role to the page. You can then select a different behavior for each action.
- Click Save to make the changes effective.
Configuring Atomic Security on User & System Actions
Atomic Security allows you to control which object actions or lifecycle actions are hidden, viewable, or executable for object records by lifecycle state and role. Settings you configure through Atomic Security cannot provide more access than a user has through the security profile. For example, Tracy Lee’s security profile does not grant the Workflow > Start permission. If she’s assigned to an application role that is granted Execute permission for Send Quality Review, she still cannot perform the action because it would start a workflow.
When defining Atomic Security for user actions on objects, you must first define a default access level for each lifecycle state. All roles will have that access level on object records within the state. You can then apply overrides for certain application roles. For example, in VeePharm’s Quality Vault, the Quality Event Lifecycle uses the Initiated lifecycle state, which contains the Send for Impact Assessment and Send for Quality Review actions. Although VeePharm may want these actions viewable for all roles, they only want to enable those in the Owner role to execute each action. To do this, a VeePharm System Admin, configures Atomic Security on the actions, and then sets the State Behavior to View. He then uses Role Override to apply the Execute permission to the Owner role on each action.
Behavior Options
When setting a default and override behavior, you see the following options:
- Hide: The action is never visible to users and does not appear in the Actions menu.
- View: Allows users to see the action in the Actions menu, but they cannot select it because it is grayed out.
- Execute: Allows users to see and click on the action in the Actions menu.
How to Set Atomic Security on User & System Actions
To set up Atomic Security on user and system actions:
- Navigate to Admin > Configuration > Object Lifecycles. Click into a lifecycle and then into an individual state.
- From the Atomic Security: Actions section, click Edit.
- Select Execute (default), View, or Hide from the State Behavior picklist to apply the security setting to each action.
- Optional: Click + Role Override to add an Application Role to override the state behavior. This option adds the selected role to the page. You can then select a different behavior for each action.
- Click Save to make the changes effective.
Configuring Atomic Security on Active Workflow Actions
Active workflow actions are options for workflow instances that are in progress, for example, Add Participants and Cancel Workflow. By default, in Vaults that do not use Atomic Security for Objects, access to these actions is granted automatically to the workflow owner and also granted via permission sets. When you enable Atomic Security, workflow owners will continue to have access to these actions regardless of permission sets.
Behavior Options
When setting a default and override behavior, you see the following options:
- Execute: Allows users to see and click on the action.
- Hide: The action is never visible to users.
How to Set Atomic Security on Active Workflow Actions
To set up Atomic Security on active workflow actions:
- Navigate to Admin > Configuration > Object Lifecycles. Click into a lifecycle and then into an individual state.
- From the Atomic Security: Actions section, click Edit.
- Select Execute (default), View, or Hide from the State Behavior picklist to apply the security setting to each action.
- Optional: Click + Role Override to add an Application Role to override the state behavior. This option adds the selected role to the page. You can then select a different behavior for each action.
Click Save to make the changes effective.
Configuring Atomic Security on Relationships
Atomic Security on relationships allows you to control when inbound relationships on object records or documents can be modified according to object lifecycle state and user role.
Atomic Security on relationships controls which users can relate an object record or document. For example, VeePharm’s Campaign object has a document field, Budget Proposal, which creates a relationship between a specific campaign (the object record) and a specific document. An Admin can configure Atomic Security so that only users in the Campaign Coordinator role can edit this relationship (link a campaign to a budget document, or unlink it) in most lifecycle states, and even that role is prevented from editing once the record goes into Approved state. Users who are not in the Campaign Coordinator role will see the relationship to the budget document, but they cannot remove it or link another document through that relationship.
You can use Atomic Security to define a default state behavior for object or document relationships. When configured, all roles will have the default access on object relationships within that specific state. For example, in VeePharm’s Quality Vault, once the Complaint object record is in CAPA Approval state, users should not assign a new Investigation or delete an existing Investigation related to the Complaint. To prevent users from adding or removing related Investigation records, an Admin uses Atomic Security to set the relationships between the Complaint and Investigations objects to Read. With her configuration, the relationship is read-only while in the CAPA Approved state.
Behavior Options
When setting a default and override behavior, you see the following options:
- Edit: Allows a user to edit relationships without restrictions.
- Read: Relationships are read-only. Users cannot relate documents or related objects to the object record or remove an existing relationship.
How to Enable Atomic Security on Object-to-Object Relationships
Object-to-object relationships are controlled by configuring Atomic Security on object-type fields on an object. To enable Atomic Security on object-to-object relationships:
- Navigate to Admin > Configuration > Objects > [Object] > Relationships.
- Select the desired object reference or parent object reference field.
- Click Edit.
- Select the Secure relationship checkbox. Note that this option is only available on object reference and parent object reference fields assigned to a lifecycle. Note that this checkbox is only selectable if the referenced object is assigned to a lifecycle.
- Click Save to make the relationship configurable via the object’s lifecycle.
How to Enable Atomic Security on Document-to-Object Relationships
Document-to-object relationships are controlled by configuring Atomic Security on object-type document fields. To enable atomic security on object types of document field relationships:
- Navigate to Admin > Configuration > Document Fields.
- Click on the object type of document field.
- Click Edit.
- Select the Secure based on the states and roles of the referenced object records checkbox. Note that this checkbox is only selectable if the referenced object is assigned to a lifecycle
- Click Save to make the relationship configurable via the object’s lifecycle.
How to Set Atomic Security on Relationships
To set up Atomic Security on relationships:
- Navigate to Admin > Configuration > Object Lifecycles. Click into a lifecycle and then into an individual state.
- From the Atomic Security: Relationships section, click Edit.
- Select Edit (default) or Read from the State Behavior picklist to apply the security setting to each relationship.
- Optional: Click + Role Override to add an Application Role to override the state behavior. This option adds the selected role to the page. You can then select a different behavior for each action.
- Click Save to make the changes effective.
How Vault Applies Atomic Security on Relationships
Atomic Security on Record-to-Record Relationships
- When creating and saving a new record, Vault checks if the record can be saved based on the security settings. Users cannot create new records if at least one object reference refers to a record where the relationship has the Read permission. On save, Vault validates each object reference field with a secured inbound relationship and displays an inline error message on object reference fields that fail validation.
- When editing and saving a record with an object reference field that has the Edit permission, Vault validates if the referenced record can be reassigned based on inbound relationship Atomic Security.
- Users cannot inline edit an object reference field in a related list if the corresponding inbound relationship on the object has the Read permission.
- If an object record has at least one object reference field with the Disable permission, the Delete action is not visible to the user.
Atomic Security on Document-to-Record Relationships
- Vault honors Atomic Security on relationships when editing document fields from the Doc Info page, as well as when you delete a document or document version, copy a document or object record, or edit an object reference field.
- When you create a draft, Vault clears out relationships fields secured by Atomic Security.
- Atomic Security on relationships will not prevent you from versioning a document.