--- sourceDocument: Australia Governance, Risk, and Compliance sourceDocumentLink: https://www.servicenow.com/docs/r/australia/governance-risk-compliance Release : - australia ft:locale : - en-US ft:publication_title : - Australia Governance, Risk, and Compliance ft:clusterId : - grc bundleId : - grc workflow : - Technology --- # File Access Configuration # File access permissions {#ariaid-title1} Release version: Australia Updated March 12, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of File access permissions Workspace administrators with thesngrcworkspace.adminrole in ServiceNow GRC can configure file access permissions for users and groups. These permissions control how users interact with files linked to GRC records, such as policies, controls, and engagements. Show full answer Show less ## Key Features * **Unique File Access Records:** Only one file access permission record can exist per combination of Table field, Access permission, and Users field to avoid duplicates. * **Cloud File Configuration:** Only one active cloud file configuration is allowed per combination of Table field and Provider. * **Access Hierarchy:** Users belonging to multiple groups or user fields receive the highest level of access granted across those groups. * **Source and Reference Links:** * A cloud file's first connection to a GRC record is a **source link** with write access. * Subsequent connections to other GRC records are **reference links** with read-only access. * Permissions on source links are applied as configured, while reference links always have read access, even if configured otherwise. * **Dynamic Source Link Reassignment:** If the source link mapping is removed, the next mapped GRC record becomes the new source link, inheriting write access. * **Request Access and Refresh Actions:** * By default, file access permissions are enabled on engagement and audit task records. * Users in groups can request access to files via the **Request access** UI action, which is a one-time activity per user. * Users specified in cloud file configurations can refresh their access using the **Refresh file access** action. * If a request is already granted or not processed timely, appropriate UI messages guide the user. * **Extensibility:** File access permissions can be configured on other tables like control or policy records, with advanced configuration options referenced in KB1587297. ## Practical Implications for ServiceNow Customers Administrators can precisely control who can read or write to files linked to GRC records, ensuring secure and compliant document management. The distinction between source and reference links guarantees that only the primary linked record has write permissions, reducing the risk of unauthorized modifications. The Request access and Refresh file access actions empower users and groups to manage their permissions efficiently, with system feedback to avoid confusion. By following these configurations, customers can maintain robust governance over file access in their GRC workspace, streamline collaboration among contributors and reviewers, and ensure compliance with organizational policies regarding sensitive documents. The Workspace administrators with the sn_grc_workspace.admin role can configure the file access permissions for the users and groups. ## Conditions for file access permissions {#file-access-permissions__section_n1q_bs4_4zb} The Workspace administrators with the sn_grc_workspace.admin role can configure different conditions for file access permissions: * For a combination of the Table field, Access permission field, and Users field, you can have only one File access permission record. Duplicate records with the same access permissions are not permitted. For example, if a contributor has Read access permission for the policy (sn_compliance_policy) record, creating another record for the same condition is not permitted. * For a given combination of the Table field, Provider field, and Active option, only one Cloud file configuration record is permitted. A duplicate configuration is not permitted for an active table as shown in the following example. * If a user is part of multiple User fields or a Group field, a higher access is granted to the user. {#file-access-permissions__ul_wty_5s4_4zb} ## Source link and reference link to the GRC record {#file-access-permissions__section_jhr_tt4_4zb} When a cloud file is connected to a GRC record for the first time, the connection is considered as a source link to the GRC record. When the same cloud file is mapped to another GRC record, then it is considered as a reference link to the GRC record. A source link to the GRC record always has the write access and the reference link to the GRC record always has the read access. When a record is mapped as a source link to the cloud file, the configuration is applied as it is to the cloud file. For example, if the configuration contains write access for some users and read access for some users, the same configuration is maintained and applied to the users. The Document reference table shows how one document record is being referenced such as its source link and reference link to the GRC record. The following example shows the Document reference table. Consider the example of Engagement_memo.xslx for which Control test CTR0020005 is a source link and Control test CTR0020004 is a reference link. For any configuration that matches the configuration of Control test CTR0020004, all users under this configuration have only read access. This applies even though they have Write access in the configuration. Consider the following example where a Risk and Controls Matrix Report is connected to Engagement record 1 and Engagement record 2. {#file-access-permissions__table_er1_cw4_4zb__entry__2} | Document | Record that the document is connected to | |-|-| | Risk and Controls Matrix Report | Engagement record 1. It is the source for the access document. | | Risk and Controls Matrix Report | Engagement record 2. It is the reference for the access document. | [Table 1. Example: Access document and the associated records] {#file-access-permissions__table_er1_cw4_4zb}See the following table for the permissions assigned for the example.{#file-access-permissions__table_ayg_3w4_4zb__entry__4} | Access doc connected to the record | Users field value | Type of access | Description | |-|-|-|-| | Engagement record 1 | Contributors | Have Write access | For the source record, the permission configuration is considered as it is configured. Therefore, the contributors have the Write access to Engagement 1. | | Engagement record 2 | Reviewers | Have Write access | The same access record is mapped to Engagement 2, for which the reviewers should have the Write access. Because Engagement record 2 is a reference record, the reviewers have the Read access instead of the Write access. | [Table 2. Example: Assigned access permissions] {#file-access-permissions__table_ayg_3w4_4zb} ## Another use case for source link {#file-access-permissions__section_lxr_pd3_c1c} When the cloud document is mapped to a record, it becomes a source link for the cloud document. If the same record is removed and the cloud document is mapped to another GRC record, the next record becomes the source link for the cloud document. For example, the Engagement_memo.xlsx file is mapped to the engagement 1 and engagement 2 records. The engagement 1 record is the source link and the engagement 2 record is the reference link. If the mapping between the Engagement_memo.xlsx file and the engagement 1 record is removed, the Engagement_memo.xlsx file does not have any source link. If the Engagement_memo.xlsx file is mapped to the engagement 3 record, then the engagement 3 record becomes the source link for the document. ## Request access and Refresh file access actions {#file-access-permissions__section_k1w_5xh_c1c} By default, the file access permissions are enabled on the engagement and audit task records. For other records, you can use the Request access and Refresh file access actions on the form. By default, the file access permissions are enabled on the engagement and audit task records. If a user is part of a group, they can use the Request access UI action to request access to the file. The Request access UI action is available only to the group members. If the user is part of a cloud file configuration, they can use the Refresh file access action to refresh or configure the file access. The Refresh file access action is available to the users mentioned in the cloud file configuration. You can configure file access permissions on other tables such as control records or policy records. Instead of using the manual Request access and Refresh file access actions, see the configuration steps in KB1587297. The users that are part of a group should request access to the cloud file by using the Request access action button. When a user who is part of the Audit Managers group selects Request access on the form, a UI message is displayed as shown in the example: The file access is being processed. Requesting access to the cloud file is a one-time activity for the users of a group. If a user selects Request access more than once and the access has already been granted, the following message is displayed: File access has already been granted. If the user requests access to the cloud file and if the request is not processed in time, an error message is displayed on the screen. The user must select Refresh file access to request an access to the file again.