---
sourceDocument: Australia Customer Service Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/pt-BR/customer-service-management

 Release :

    - australia

ft:locale :

    - pt-BR

ft:publication_title :

    - Australia Customer Service Management

ft:clusterId :

    - csm

bundleId :

    - csm

workflow :

    - Customer and Industry


---

# Creating a responsibility access configuration

# Creating a responsibility access configuration {#ariaid-title1}

* Versão de lançamento: Australia
* 
* Atualizado 12 de mar. de 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 min. de leitura

Create responsibility access configurations to add or modify access for various user relationships using different association types.

Administrators can use these configurations to define the roles required to access specific table records, including the level of access. With new filters and table mappings, you can model granular relationships that represent a wide
range of responsibilities within your organization.

For example, starting with the Zurich release, account manager responsibility access configuration is introduced out of the base system. Using this responsibility, you can assign the account manager responsibility to a specific account. This
configuration grants access to account information, along with related entities such as cases, sold products, and more.

## Association types {#creating-responsibility-access-configuration__section_nss_jds_bgc}

As an administrator, you can use this flexible framework to either create a responsibility with customized access rules or modify existing configurations as needed. You can create responsibility access configurations for various relationship patterns using appropriate association types.

* Simple association
* Dependent association
* Advanced association
{#creating-responsibility-access-configuration__ul_w5g_czp_bgc}

## Simple association {#creating-responsibility-access-configuration__section_nbj_1xp_bgc}

You can use this association when there's a direct relationship between the user and the target record. This association type uses direct field matching and doesn't require
intermediate tables or custom logic.  
Figura 1. Simple association workflow
Simple association workflow

This scenario explains how access to case records is granted based on a user's direct relationship to the associated account. For example, Anna is an account manager for the
customer account XYZ company. They need access to case records that are directly linked to XYZ company. As the case record includes a field for the associated account, the system can easily validate Anna's access based on the role
and the account ID.

The system determines Alex's access using the following logic:

* Anna opens a case record.
* The system identifies the account associated with the case.
* It checks the account team member table to find a record where:
  * The user is Anna
  * The responsibility is the account manager
  * The account matches the account listed on the case
  {#creating-responsibility-access-configuration__ul_rqs_b1q_bgc}
* If a matching record is found, access to the case is automatically granted.

{#creating-responsibility-access-configuration__ul_qqs_b1q_bgc}

This approach confirms that access is granted efficiently when there's a clear, one-to-one relationship between the user and the account associated with the case.

## Dependent association {#creating-responsibility-access-configuration__section_ogj_q1q_bgc}

You can use this association when access must be determined through an intermediate relationship, often involving a many-to-many (M2M) table. This setup is common when a
requester's connection to a record is established indirectly through related items.  
Figura 2. Dependent association workflow
Dependent association workflow

This scenario explains how access to case records is granted based on a requester's relationship to install base items associated through an intermediate table. For example,
Alex is a team member with authorized account responsibility and require access to specific case records that are tied to install base items. Alex's access depends on whether these case records are listed as an authorized party for
any of those items. However, the relationship between the case and the install base item isn't direct, but it's maintained through a separate affected install base table.  
The system determines Alex's access using the following logic:

* Alex opens a case record.
* The system checks if the case is linked to any install base items using the affected install base table.
* It retrieves the install base items associated with the case.
* The system checks if Alex is listed with the authorized account role for any of the install base items in the related party table.
* If Alex holds the required role for any matching item, access to the case record is automatically granted.
{#creating-responsibility-access-configuration__ul_myb_jcq_bgc}This approach confirms that access is granted only when a valid relationship exists between the requester and install base items, enforcing secure access even through indirect associations.

## Advanced association {#creating-responsibility-access-configuration__section_zf4_bdq_bgc}

You can use this association in complex scenarios where simple relationship-based access is insufficient. This association type relies on custom script logic to validate
requester's access across multiple related records.  
Figura 3. Advanced association workflow
Advanced association workflow

This scenario explains how access to escalation records is determined based on the requester's relationship to the associated account.

For example, Anna is an account
manager who needs access to specific escalation records. Some of these escalation records are tied to cases, which are in turn associated with accounts Anna manages. A custom script identifies the related accounts and verifies
Anna's role before granting access to the escalation records.  
The system determines Alex's access using the following logic:

1. Anna opens an escalation record.
2. The system checks the escalation's source:
   * If the escalation is linked to a customer case, the system identifies the account associated with that case.
   * If the escalation is directly linked to an account, the system uses the account record.
   {#creating-responsibility-access-configuration__ul_pvz_ldq_bgc}
3. The system verifies if Anna is assigned as the account manager for the identified account.
4. If Anna is assigned to the account, access to the escalation record is automatically granted.
{#creating-responsibility-access-configuration__ol_ovz_ldq_bgc}This approach confirms that access is granted only when a clear relationship exists between the user and account, whether the link is direct or through a related case.