Criação de uma configuração de acesso de responsabilidade

  • Versão de lançamento: Zurich
  • Atualizado 31 de jul. de 2025
  • 4 min. de leitura
  • Crie configurações de acesso de responsabilidade para adicionar ou modificar o acesso a vários relacionamentos de usuário usando diferentes tipos de associação.

    Os administradores podem usar essas configurações para definir as funções necessárias para acessar registros de tabela específicos, incluindo o nível de acesso. Com novos filtros e mapeamentos de tabela, você pode modelar relacionamentos granulares que representam uma ampla gama de responsabilidades em sua organização.

    Por exemplo, começando com Zurich a configuração de acesso à responsabilidade do gerente de contas foi introduzida fora do sistema de base. Usando essa responsabilidade, você pode atribuir a responsabilidade do gerente de conta a uma conta específica. Esta configuração concede acesso às informações da conta, junto com entidades relacionadas, como casos, produtos vendidos e muito mais.

    Tipos de associação

    Como administrador, você pode usar essa estrutura flexível para criar uma responsabilidade com regras de acesso personalizadas ou modificar as configurações existentes conforme necessário. Você pode criar configurações de acesso de responsabilidade para vários padrões de relacionamento usando tipos de associação apropriados.
    • Associação simples
    • Associação dependente
    • Associação avançada

    Associação simples

    Você pode usar essa associação quando houver um relacionamento direto entre o usuário e o registro de destino. Este tipo de associação usa correspondência de campo direta e não requer tabelas intermediárias ou lógica personalizada.

    Figura 1. Fluxo de trabalho de associação simples
    Uma captura de tela exibindo como o acesso aos registros de caso é concedido usando uma associação de relacionamento simples.
    Fluxo de trabalho de associação simples

    Este cenário explica como o acesso aos registros de caso é concedido com base no relacionamento direto de um usuário com a conta associada. Por exemplo, Anna é gerente de conta da empresa XYZ da conta do cliente. Eles precisam de acesso a registros de caso que estão diretamente vinculados à empresa XYZ. Como o registro de caso inclui um campo para a conta associada, o sistema pode validar facilmente o acesso de Ana com base na função e no ID da conta.

    O sistema determina o acesso de Alex usando a seguinte lógica:

    • Anna abre um registro de caso.
    • O sistema identifica a conta associada ao caso.
    • Ele verifica a tabela de membros da equipe da conta para encontrar um registro em que:
      • O usuário é Anna
      • A responsabilidade é o gerente de conta
      • A conta corresponde à conta listada no caso
    • Se um registro correspondente for encontrado, o acesso ao caso será concedido automaticamente.

    Esta abordagem confirma que o acesso é concedido de forma eficiente quando há um relacionamento claro e um para um entre o usuário e a conta associada ao caso.

    Associação dependente

    Você pode usar essa associação quando o acesso precisar ser determinado por meio de um relacionamento intermediário, geralmente envolvendo uma tabela muitos para muitos (M2M). Esta configuração é comum quando a conexão de um solicitante a um registro é estabelecida indiretamente por meio de itens relacionados.

    Figura 2. Fluxo de trabalho de associação dependente
    Uma captura de tela exibindo como o acesso aos registros de caso é concedido usando uma associação de relacionamento dependente.
    Fluxo de trabalho de associação dependente

    Este cenário explica como o acesso a registros de caso é concedido com base no relacionamento de um solicitante para instalar itens-base associados por meio de uma tabela intermediária. Por exemplo, Alex é um membro da equipe com responsabilidade de conta autorizada e requer acesso a registros de caso específicos vinculados a itens-base de instalação. O acesso de Alex depende se esses registros de caso estão listados como uma parte autorizada para qualquer um desses itens. No entanto, o relacionamento entre o caso e o item-base de instalação não é direto, mas é mantido por meio de uma tabela-base de instalação afetada separada.

    O sistema determina o acesso de Alex usando a seguinte lógica:
    • Alex abre um registro de caso.
    • O sistema verifica se o caso está vinculado a algum item-base de instalação usando a tabela-base de instalação afetada.
    • Recupera os itens-base de instalação associados ao caso.
    • O sistema verifica se Alex está listado com a função de conta autorizada para qualquer um dos itens-base de instalação na tabela de partes relacionadas.
    • Se Alex tiver a função necessária para qualquer item correspondente, o acesso ao registro do caso será concedido automaticamente.
    Esta abordagem confirma que o acesso é concedido somente quando existe um relacionamento válido entre o solicitante e os itens-base de instalação, impondo o acesso seguro mesmo por meio de associações indiretas.

    Associação avançada

    Você pode usar essa associação em cenários complexos em que o acesso simples baseado em relacionamento é insuficiente. Este tipo de associação depende da lógica de script personalizada para validar o acesso do solicitante em vários registros relacionados.

    Figura 3. Fluxo de trabalho de associação avançada
    Uma captura de tela exibindo como o acesso aos registros de caso é concedido usando uma associação de relacionamento avançada.
    Fluxo de trabalho de associação avançada

    Este cenário explica como o acesso aos registros de escalação é determinado com base no relacionamento do solicitante com a conta associada.

    Por exemplo, Anna é uma gerente de conta que precisa de acesso a registros de escalação específicos. Alguns desses registros de escalação estão vinculados a casos, que, por sua vez, estão associados a contas gerenciadas por Ana. Um script personalizado identifica as contas relacionadas e verifica a função de Ana antes de conceder acesso aos registros de escalação.

    O sistema determina o acesso de Alex usando a seguinte lógica:
    1. Anna abre um registro de escalação.
    2. O sistema verifica a origem da escalação:
      • Se a escalação estiver vinculada a um caso de cliente, o sistema identificará a conta associada a esse caso.
      • Se a escalação estiver diretamente vinculada a uma conta, o sistema usará o registro da conta.
    3. O sistema verifica se Anna foi atribuída como gerente de conta da conta identificada.
    4. Se Anna for atribuída à conta, o acesso ao registro de escalação será concedido automaticamente.
    Esta abordagem confirma que o acesso é concedido somente quando existe um relacionamento claro entre o usuário e a conta, seja o link direto ou por meio de um caso relacionado.