Contas com HIPAA ativado:

Todos os termos em maiúsculas usados neste documento devem ter os significados atribuídos a eles no Business Associate Agreement ("BAA") da Zendesk. 

A Zendesk e o Assinante firmaram um Business Associate Agreement ("BAA") que exige que o Assinante avalie e implemente, conforme apropriado para seu caso de uso, as seguintes configurações ou alternativas avaliadas pelo Assinante como substancialmente semelhantes, para todo e qualquer HIPAA Habilitado Conta(s) antes de introduzir qualquer Informação de Saúde Protegida ("PHI") nos Serviços. 

Se o Assinante escolher, a seu exclusivo critério, abandonar a implementação de qualquer uma das configurações recomendadas listadas abaixo, o Assinante assumirá a responsabilidade por qualquer acesso não autorizado ou uso indevido de divulgação dos Dados de Serviço do Assinante, incluindo quaisquer Informações de Saúde Protegidas, que resultem de tais desvios das configurações recomendadas pelo Assinante.

O assinante deve ter adquirido planos de serviço no nível apropriado e ter os complementos associados necessários (consulte seu representante de vendas em caso de dúvida)

I. As configurações de segurança mínimas a seguir para o Zendesk Support devem ser implementadas e são reconhecidas no BAA para qualquer conta com HIPAA ativado:

  1. Proteja a autenticação do agente por um dos dois métodos a seguir:
    1. Empregando o Zendesk Support nativo com configurações de senha: (i) definido como “Alto”; ou (ii) personalizado pelo Assinante de maneira que estabeleça requisitos não menos seguros do que os estabelecidos na configuração "Alta". Além disso, de acordo com a opção nesta subseção, o Assinante também deve ativar e aplicar a Autenticação de Dois Fatores ("2FA") nativamente dentro do Serviço; e os controles administrativos que permitem que os administradores definam senhas para os usuários finais devem ser desativados; ou
    2. Usar uma solução externa de Single Sign On (SSO") com requisitos estabelecidos não menos seguros do que os estabelecidos na configuração de senha "Alta" do Zendesk e ativar e aplicar a autenticação de dois fatores dentro da solução selecionada para o acesso de todos os agentes. Os controles administrativos que permitem que os administradores definam senhas para os usuários finais devem ser desativados.
    3. Todas as opções de autenticação que utilizam SSO como método de autenticação devem desativar o acesso por senha.
  2. A criptografia Secure Socket Layer ("SSL") em contas com HIPAA deve permanecer sempre ativada. Contas com HIPAA ativado que utilizam um domínio diferente de zendesk.com devem estabelecer e manter SSL hospedado.
  3. O acesso do agente deve ser restrito a endereços IP específicos sob o controle do Assinante a menos que o Assinante habilite a autenticação multifator para agentes conforme descrito acima nos requisitos 1.a ou 1.b (nativamente dentro do Serviço ou dentro do ambiente do Assinante, juntamente com o Enterprise SSO).  Para evitar dúvidas, "Acesso de agente" deve denotar o acesso concedido a um agente humano que acessa os Dados de Serviço por meio da Interface do Usuário ("IU").
  4. Na medida em que a Conta Habilitada para HIPAA do Assinante permite chamadas para as Interfaces de Programação de Aplicativos do Zendesk ("APIs"), o Assinante assumirá toda a responsabilidade por entender as implicações de segurança de todas as entidades do Assinante ou de terceiros com permissão para criar, acessar, modificar ou apagar Dados de Serviço e PHI por meio desse acesso e/ou integrações. Para acessar essas APIs, o Zendesk oferece vários métodos, conforme descrito aqui, e o Assinante deve implementar as seguintes práticas recomendadas de segurança com base no modelo de API usado:
    1. Abordagem OAuth 2.0.  Esse modelo fornece os recursos de segurança mais granulares, mas requer que os direitos sejam aceitos por um usuário final.  Sempre que possível, o Assinante utilizará a abordagem e o esquema de autenticação OAuth 2.0. O Assinante dará a cada cliente OAuth uma função descritiva e exclusiva de Nome do Cliente e Identificador Exclusivo. As permissões concedidas para cada token OAuth devem permitir o mínimo de privilégios necessários para realizar as tarefas necessárias.
    2. Abordagem do token da REST API.  Esse modelo é o mais amplo e permite que um token da API utilize toda a funcionalidade do modelo da API. Por sua natureza, ele fornece acesso e recursos mais amplos e deve ser usado com cautela. Ao usar essa abordagem, o Assinante (i) usará um token exclusivo para cada serviço e dará ao token um nome descritivo que designa a função; (ii) não compartilhar tokens da API com terceiros, a menos que seja razoavelmente necessário e de acordo com métodos de transmissão que são criptografados de ponta a ponta; (iii) reconhecer que, se o token da API for compartilhado com terceiros e o Assinante for informado de uma violação de dados de terceiros, o Assinante alternará o token associado imediatamente; e (iv) no mínimo, alterne o token com frequência de acordo com as políticas da organização do Assinante.  
    3. Quando possível, o Assinante deve desativar a senha de acesso à API, pois essa abordagem envia credenciais de usuário a cada solicitação, o que as expõe amplamente, tornando-as mais facilmente interceptáveis por terceiros mal-intencionados.  
  5. O assinante deve ativar a opção "Solicitar autenticação para download" para solicitar autenticação para acessar anexos. Não fazer isso significa que qualquer anexo irrestrito pode ser acessado por qualquer pessoa com acesso à URL correta do referido anexo. Nesses casos, o Assinante assumirá toda a responsabilidade pelo conteúdo e acesso a esses dados de anexo.
  6. O Assinante deve aplicar sistematicamente, em todos os pontos de extremidade acessados por Agentes, Administradores e Proprietários, um protetor de tela bloqueado por senha ou uma tela de inicialização configurada para interagir com, no máximo, quinze (15) minutos de inatividade do sistema.
  7. O Assinante não deve alterar as permissões de visualização que permitem que um usuário veja atualizações de uma instância/marca/organização inteira ou alterar a configuração padrão que permite acesso além dos tickets do próprio usuário (a menos que o Assinante assuma toda a responsabilidade por garantir que esses usuários sejam aprovados pelo Assinante para acessar todos dados subsequentes). O Assinante reconhece que as permissões da organização do Usuário Final podem ser definidas no perfil do usuário e na própria organização e, se as configurações forem conflitantes, a configuração mais permissiva anula a configuração menos permissiva.
  8. O Assinante reconhece que a Zendesk não é responsável por proteger as transmissões de e-mail dos Usuários Finais e os Dados de Serviço relacionados antes de serem recebidos na instância do Zendesk Support do Assinante. Isso inclui qualquer PHI que possa ser transmitida por e-mail por meio de respostas aos tickets do Zendesk Support , incluindo, entre outros, comentários ou anexos do ticket.
  9. O Assinante reconhece que o Zendesk Support envia um e-mail para um Usuário Final sob várias circunstâncias, por exemplo, quando um Agente do Assinante responde a um ticket do Zendesk Support pelo canal de e-mail ou iniciado por uma automação ou gatilho. Por padrão, esse email contém a correspondência de ticket mais recente ou outras informações configuradas para serem incluídas em uma notificação automatizada, que pode incluir PHI. Para proteger ainda mais o Assinante, sua instância do Zendesk Support deve ser configurado para alertar apenas o usuário final que um agente respondeue solicitar que o usuário final se autentique no Zendesk Support para ver o conteúdo da mensagem.
  10. O Assinante reconhece que qualquer funcionalidade de mensagem de texto utilizada a seu exclusivo critério em qualquer Serviço da Zendesk é sustentada por SMS e/ou protocolos relacionados, que podem envolver a transmissão não criptografada de mensagens enviadas para ou fora do(s) Serviço(s).  Como tal, a funcionalidade de mensagem de texto deve:
    1. não pode ser usado em uma conta habilitada para HIPAA *, ou
    2. se usado, o Assinante assume toda a responsabilidade pelo uso de tal funcionalidade
  11. O Assinante reconhece que o uso da funcionalidade legada das Pesquisas de satisfação do cliente ("CSAT legadas") do Serviço envia os Dados do Serviço (que podem conter PHI) associados ao ticket do Support por e-mail para obter a classificação do usuário, cujo status de criptografia não é controlado por Zendesk. Como tal, a funcionalidade CSAT legada deve:
    1. não pode ser usado em uma conta habilitada para HIPAA *, ou
    2. se usado, o Assinante assume toda a responsabilidade pelo uso de tal funcionalidade
  12. O Assinante reconhece que o uso da funcionalidade Pesquisas de Satisfação do Cliente ("CSAT") do Serviço para o canal de tickets, se não estiver configurado adequadamente, enviará os Dados do serviço (que podem conter PHI) associados ao ticket do Support por email para obter a classificação do usuário, cujo status de criptografia não é controlado pela Zendesk. Além disso, qualquer pessoa com a URL de CSAT específica tem acesso às respostas fornecidas para um ticket específico. Assim, ao usar a funcionalidade de CSAT para o canal de tickets, o Assinante deve
    1. Configure o corpo do email de automação de CSAT para não incluir possíveis ePHI e use o {{satisfaction.survey_url}} placeholder exclusivamente
    2. Não usar a funcionalidade de perguntas abertas

* Para evitar dúvidas, as advertências de dados relacionadas ao ePHI na seção 10 sobre SMS não se aplicam ao uso de 2FA no produto (conforme descrito na seção 1.a), pois essa funcionalidade envia apenas uma cadeia de caracteres numérica para verificação de identidade.

II. As configurações de segurança mínimas a seguir para os serviços do Zendesk Guide e Gather devem ser implementadas e são reconhecidas no BAA para qualquer conta com HIPAA ativado:

  1. O Assinante reconhece que os Serviços Guide e Gather são públicos por natureza (onde não é possível aproveitar artigos restritos ou usar uma instância fechada ou restrita) e, portanto, o Assinante deve garantir que quaisquer artigos no Zendesk Guide ou no Serviço Gather não incluam PHI, seja por meio do texto de artigo ou como anexo ou imagem dentro do artigo.
  2. O Assinante deve desativar a capacidade de os Usuários Finais adicionarem comentários no Zendesk Guide ou deve moderar e assumir a responsabilidade pela remoção de PHI de todos os comentários (conforme indicado na seção 3 abaixo).
  3. Onde o Serviço do Zendesk Guide for Guide Professional ou Enterprise, os Assinantes devem, quando possível, desativar a capacidade de os usuários finais criarem novas publicações desativando a funcionalidade Gather com o Zendesk Guide ou quando os recursos do Gather não puderem ser usados devido à intenção do Assinante caso de uso, os Assinantes devem ativar a moderação de conteúdo no Serviço do Zendesk Guide e definir como "Moderar todo o conteúdo". Nenhum envio contendo PHI será aprovado.
  4. O uso de “Moderadores da comunidade” que não sejam funcionários do Assinante não será permitido no Serviço Gather.
  5. O Assinante reconhece que "@Menções" de membros da comunidade do Gather são possíveis quando permitindo que os usuários finais tenham perfis públicos e, caso essa funcionalidade seja considerada um risco em seu caso de uso, os perfis públicos devem ser desativados ou as @Menções devem ser desativadas.

III. As configurações de segurança mínimas a seguir para o uso do recurso de mensagens do Zendesk devem ser implementadas e confirmadas no BAA do Zendesk para qualquer conta com HIPAA ativado:

  1. O Assinante não deve ativar as integrações de canais de mensagens de redes sociais, a menos que assuma total responsabilidade por (i) garantir que nenhum ePHI esteja presente nas mensagens de redes sociais ou (ii) conclua seu próprio BAA com plataformas de mensagens integradas.
  2. O Assinante deve desativar a capacidade de os Usuários Finais anexarem arquivos a conversas por mensagem e deve assumir total responsabilidade por (i) ativar anexos seguros ou (ii) garantir que os Agentes não anexem arquivos contendo ePHI a conversas por mensagem. Não fazer isso significa que qualquer anexo irrestrito pode ser acessado por qualquer pessoa com acesso à URL correta do referido anexo.  Nesses casos, o Assinante assumirá toda a responsabilidade pelo conteúdo e acesso a essas URLs e/ou dados de anexo.
  3. O Assinante assumirá toda a responsabilidade por garantir que todos os Agentes e Agentes light tenham permissão para visualizar todas as mensagens recebidas de todos os Usuários Finais.
  4. Se o Assinante ou seus Agentes acessarem ou desenvolverem integrações (por exemplo, como parte de um fluxo criado para o Answer Bot) para APIs e webhooks ou personalizarem a experiência de mensagens, o Assinante assumirá total responsabilidade por entender as implicações de privacidade e segurança de todos os fluxos de trabalho personalizados e por todos Assinantes ou entidades terceirizadas (incluindo provedores de chatbots) têm permissão para criar, acessar, modificar ou apagar Dados do Serviço e ePHI por meio desse acesso e/ou integrações.
  5. Se o Assinante desejar remover a permissão de um Agente para participar de uma conversa por mensagem enquanto a conversa por mensagem estiver ativa no momento, o Assinante assumirá toda a responsabilidade por forçar o encerramento do acesso do referido Agente ao Zendesk.
  6. Por padrão, as conversas do Web Widget com os Usuários Finais são permanentes e poderão ser visualizadas pelo Usuário Final quando ele retornar ao web chat a partir do mesmo dispositivo. O Assinante deve desativar esse recurso ou assumir toda a responsabilidade por garantir que os Usuários Finais não compartilhem dispositivos.
  7. Se o Assinante desejar implementar a autenticação para Usuários Finais, o Assinante assumirá toda a responsabilidade por implementá-la de maneira segura, de acordo com as práticas recomendadas e os padrões do setor.
    1. Ao usar essa abordagem, o Assinante (i) usará uma chave de assinatura JWT exclusiva para cada canal de autenticação e dará ao token um nome descritivo que designa a função; (ii) não compartilhar chaves de assinatura JWT com terceiros, a menos que seja razoavelmente necessário e de acordo com métodos de transmissão que são criptografados de ponta a ponta; (iii) reconhecer que, se a chave de assinatura do JWT for compartilhada com terceiros e o Assinante for informado de uma violação de dados de terceiros, o Assinante fará a alternância da chave de assinatura do JWT associada imediatamente; e (iv) no mínimo, alterne a chave de assinatura do JWT com frequência de acordo com as políticas da organização do Assinante.
    2. O Assinante deve usar o atributo JWT de validade e definir seu valor como não mais que 15 minutos.
  8. O Assinante reconhece que as interações entre os Usuários Finais e o Answerbot que não são transferidas para um agente humano e transferidas para um ticket ainda estão armazenadas no sistema e que é responsabilidade do Assinante apagá-las de acordo com suas obrigações (por exemplo, implementando um webhook que alerta o Assinante quando essas conversas são armazenadas e (automaticamente) aciona a exclusão pela API do Sunshine Conversations ). 
  9. O Assinante reconhece que as conversas entre Usuários finais e o Answerbot que foram transformadas em um ticket não pode ser suprimido no momento. A exclusão é possível apagando o ticket. 
  10. O Assinante reconhece que os anexos do Usuário Final nos canais de mensagens não são verificados quanto a malware no Zendesk no momento. O Assinante deve assumir total responsabilidade por implementar procedimentos e políticas para mitigar o risco para os ativos do Assinante. 

IV. As configurações de segurança mínimas a seguir para o uso do Zendesk Sunshine Conversations (em uso com a Zendesk Suite) devem ser implementadas e são confirmadas no BAA do Zendesk para qualquer conta com HIPAA ativado:

  1. O Assinante não deve ativar integrações de canais de terceiros, a menos que assuma total responsabilidade por garantir que (i) nenhum ePHI esteja presente em mensagens de canal de terceiros ou (ii) conclua seu próprio BAA com plataformas de mensagens integradas.
  2. O Assinante assumirá toda a responsabilidade por entender as implicações de segurança de todas as entidades do Assinante ou de terceiros com permissão para criar, acessar, modificar ou apagar Dados de Serviço e PHI por meio das Interfaces de Programação de Aplicativos do Sunshine Conversations ("APIs"). Para acessar essas APIs, o Assinante deve implementar as seguintes práticas recomendadas de segurança com base no modelo de API usado:
    1. Abordagem OAuth 2.0.  Esse modelo fornece os recursos de segurança mais granulares, mas requer que os direitos sejam aceitos por um usuário final.  Sempre que possível, o Assinante utilizará a abordagem e o esquema de autenticação do OAuth 2.0. O Assinante dará a cada cliente OAuth uma função descritiva e exclusiva de Nome do Cliente e Identificador Exclusivo. 
    2. Abordagem do token da REST API.  Esse modelo é o mais amplo e permite que um token da API utilize toda a funcionalidade do modelo da API.  Por sua natureza, ele fornece acesso e recursos mais amplos e deve ser usado com cautela. Ao usar essa abordagem, o Assinante (i) usará um token exclusivo para cada serviço e dará ao token um nome descritivo que designa a função; (ii) não compartilhar tokens da API com terceiros, a menos que seja razoavelmente necessário e de acordo com métodos de transmissão que são criptografados de ponta a ponta; (iii) reconhecer que, se o token da API for compartilhado com terceiros e o Assinante for informado de uma violação de dados de terceiros, o Assinante alternará o token associado imediatamente; e (iv) alternar o token com frequência de acordo com a política da organização do Assinante.  
    3. Se o Assinante ou seus Agentes acessarem ou desenvolverem integrações para APIs e webhooks ou personalizarem a experiência do Sunshine Conversations , o Assinante assumirá total responsabilidade por entender as implicações de privacidade e segurança de todos os fluxos de trabalho personalizados e de todas as entidades do Assinante ou de terceiros (incluindo provedores de chatbot) permitidas para criar, acessar, modificar ou apagar Dados do Serviço e ePHI por meio desse acesso e/ou integrações.
  3. O Assinante reconhece que as restrições de IP configuradas para o Zendesk Support não se estendem à API do Sunshine Conversations . Os assinantes devem assumir total responsabilidade por restringir o acesso à API do Sunshine Conversations e aos tokens da API, conforme descrito em 2.b. e de acordo com as políticas do Assinante. 
  4. O Assinante deve desativar a capacidade de os Usuários Finais anexarem arquivos às conversas do Sunshine Conversations e deve assumir total responsabilidade por ativar anexos seguros ou garantir que os agentes não anexem arquivos contendo ePHI a conversas por mensagem. Não fazer isso significa que qualquer anexo irrestrito pode ser acessado por qualquer pessoa com acesso à URL correta do referido anexo. Nesses casos, o Assinante assumirá toda a responsabilidade pelo conteúdo e acesso a esses dados de anexo.
  5. Se o Assinante desejar implementar a Autenticação para Usuários Finais, o Assinante assumirá toda a responsabilidade por implementá-la de maneira robusta, de acordo com as práticas recomendadas de segurança e os padrões do setor.
    1. Ao usar essa abordagem, o Assinante (i) usará uma chave de assinatura JWT exclusiva para cada canal de autenticação e dará ao token um nome descritivo que designa a função; (ii) não compartilhar chaves de assinatura JWT com terceiros, a menos que seja razoavelmente necessário e de acordo com métodos de transmissão que são criptografados de ponta a ponta; (iii) reconhecer que, se a chave de assinatura do JWT for compartilhada com terceiros e o Assinante for informado de uma violação de dados de terceiros, o Assinante fará a alternância da chave de assinatura do JWT associada imediatamente; e (iv) no mínimo, alterne a chave de assinatura do JWT com frequência de acordo com as políticas da organização do Assinante.
    2. O Assinante deve usar o atributo JWT de validade e definir seu valor como não mais que 15 minutos.
  6. O Assinante reconhece que as interações entre os Usuários Finais e o Answerbot que não são entregues a um Agente humano e transferidas para um ticket ainda estão armazenadas no sistema e é responsabilidade do Assinante apagá-las de acordo com suas obrigações, por exemplo, implementando um webhook que alerta o Assinante quando essas conversas são armazenadas e (automaticamente) aciona a exclusão por meio da API do Sunshine Conversations 
  7. O Assinante reconhece que as conversas entre Usuários finais e o Answerbot que se transformaram em um ticket não podem ser suprimidas no momento. A exclusão é possível apagando o ticket. 
  8. O Assinante reconhece que as mensagens apagadas pela API do Sunshine Conversations são apagadas apenas para os Usuários Finais, mas não são apagadas no Espaço de trabalho do agente do Zendesk. Isso pode ser feito com a exclusão do próprio ticket ou o uso da funcionalidade Supressão (consulte Limitações 7.). 
  9. O Assinante reconhece que todos os anexos nos canais do Sunshine Conversation não são verificados quanto a malware no Zendesk. O Assinante deve assumir total responsabilidade por implementar procedimentos e políticas para mitigar o risco para os funcionários do Assinante. 

V. As configurações de segurança mínimas a seguir para o serviço do Zendesk Chat devem ser implementadas e são reconhecidas no BAA para qualquer conta com HIPAA ativado:

  1. O Assinante deve limitar o acesso dos Agentes ao Serviço do Zendesk Chat e autenticando pelo Serviço do Zendesk Support .
  2. O Assinante não deve enviar transcrições do Chat por e-mail, (a) desativando o encaminhamento por e-mail, (b) desativando a opção de transcrição do chat por e-mail no Web Widget e (c) não compartilhando exportações por e-mail do painel do Chat
  3. O Assinante não deve ativar o "Espaço de trabalho do agente", a menos que assuma total responsabilidade por garantir (i) que nenhum ePHI esteja presente nos Chats e/ou (ii) que todos os Agentes tenham permissão para visualizar esses dados.

VI. As configurações de segurança mínimas a seguir para o uso do serviço do Zendesk Explore devem ser implementadas e são reconhecidas no BAA para qualquer conta com HIPAA ativado:

O Assinante reconhece que as ePHI podem ser exibidas no produto Explore por meio de nomes de usuário, títulos de ticket, opções de campo e formulário e qualquer conteúdo encontrado em campos de texto de formato livre.

  1. Para quaisquer instâncias de Serviço no escopo que contenham PHI, o Assinante deverá (i) conceder acesso à interface do Explore apenas aos agentes que puderem acessar todos os tickets/chamadas/chats que possam conter PHI nas instâncias de Serviço pai e (ii) concederá esse acesso levando em consideração o mínimo de privilégios necessários para o uso do Explore em seu ambiente. Para obter mais informações sobre a configuração de níveis de acesso no Explore, consulte aqui.
  2. Ao aproveitar a funcionalidade de "exportação", (i) o Assinante reconhece que as PHI podem ser transferidas para o dispositivo permitido pelo Assinante para acessar a interface do agente e todos os controles de atendimento nesses dispositivos são de responsabilidade do Assinante e (ii) o Assinante deve negar o uso da funcionalidade de exportação nativa por e-mail para os referidos relatórios exportados, a menos que assuma a responsabilidade de (a) garantir que nenhuma PHI esteja contida nessas exportações ou (b) que os serviços de e-mail usados para essas transferências possam acomodar a criptografia por meio do protocolo de criptografia mínimo permitido pelos padrões PCI então vigentes.

* Considerações especiais para o uso do Explore Enterprise:

O Assinante reconhece que o uso do Serviço Explore Enterprise pode implicar em mais recursos de compartilhamento e exportação de dados. O Assinante deve:

  1. (i) garantir que não existam ePHI nesses painéis e/ou (ii) compartilhar painéis apenas com agentes, grupos, listas ou usuários finais aprovados para visualizar e receber esses dados.
  2. aproveitar restrições de IP
  3. ao compartilhar painéis por URL (Uniform Resource Locator), o Assinante reconhece que, em vez de compartilhar com contas de usuários individuais ou em grupo, os dados devem ser compartilhados por um link de acesso. Portanto, o Assinante deve (i) ativar a proteção por senha, (ii) garantir que a complexidade, a rotação, o armazenamento e a distribuição das senhas escolhidas para a parte destinatária estejam em conformidade com as políticas de senha do Assinante para a proteção dos dados contidos nesses painéis e (iii) seja alternado sem demora indevida após a suspeita ou confirmação da exposição

VII. Aviso sobre a funcionalidade no produto para serviços associados implantados (“Complementos”):

  1. Serviço associado implantado do Collaboration: “Conversas paralelas”. O Assinante reconhece que o uso da funcionalidade "Conversas paralelas" pode resultar na criação de mensagens de "ticket dependente" e/ou "conversa paralela" dentro ou enviadas da instância de Support do Assinante para destinatários por ticket, e-mail, Slack ou integrações (a critério do agente de configuração) . Se o Assinante optar por usar essa funcionalidade em uma Conta Habilitada para HIPAA , o Assinante assumirá toda e qualquer responsabilidade por (i) garantir que nenhuma PHI esteja presente em tais mensagens ou (ii) se PHI puder estar presente em mensagens, o Assinante é o único responsável por qualquer responsabilidade, custo, dano ou dano relacionado à aquisição, acesso, uso ou divulgação não autorizados de PHI resultantes da troca de mensagens por meio da funcionalidade “Conversas paralelas”.

VIII. As configurações de segurança mínimas a seguir para o uso dos aplicativos móveis do Zendesk (ou acesso feito por dispositivos móveis, como smartphones ou tablets) devem ser implementadas e são confirmadas no BAA do Zendesk para qualquer conta com HIPAA ativado:

  1. O uso deve incluir criptografia no nível do dispositivo
  2. O acesso biométrico ou PIN definido para a configuração de dispositivo mais alta permitida deve ser aproveitado
  3. As notificações que permitem que os comentários do ticket sejam exibidos nas telas de bloqueio desses dispositivos serão desativadas
  4. Os bloqueios por inatividade de tela devem ser ativados e configurados para serem bloqueados a não mais de 15 minutos de inatividade.
  5. O Assinante reconhece que o Aplicativo para dispositivos móveis do Zendesk Support não exibe se os anexos foram verificados e detectados como malware e que os Agentes precisam entrar pelo Navegador para visualizar essas informações. O Assinante deve assumir total responsabilidade por implementar procedimentos e políticas para mitigar possíveis riscos.
  6. O Assinante reconhece que a funcionalidadede supressão não está disponível no aplicativo para dispositivos móveis do Support e que os agentes precisam entrar pelo navegador caso desejem usar a funcionalidade de supressão.
  7. Se o Assinante optar por autenticar os Usuários Finais para o recurso de mensagens do Zendesk, o Assinante reconhece que o status de autenticação de um Usuário Final não é exibido no Aplicativo para dispositivos móveis do Support .

IX. Para assinantes que assinaram o BAA do Zendesk e, posteriormente, usaram o Zendesk Insights Service, nosso suporte a esse serviço será descontinuado a partir de 5 de fevereiro de 2021.   

X. Aviso sobre a funcionalidade de inteligência artificial do Zendesk (“IA do Zendesk”, “IA avançada”, “IA generativa” e outros):

  1. O Assinante reconhece que os recursos de IA do Zendesk têm como objetivo aumentar a produtividade dos Serviços do Zendesk e não devem ser usados de maneira que possa ser interpretada como (i) fornecimento de conselhos médicos ou de saúde, (ii) fornecimento de um diagnóstico de condição ou sintomas, (iii) prescrever um tratamento ou (iv) impedir de qualquer maneira que um usuário busque aconselhamento, diagnóstico ou tratamento de um profissional de saúde, (v) fornecer informações a um usuário ou tomar decisões, incluindo ou não o escopo de qualquer plano de saúde, programa de tratamento, serviço de teste ou qualquer outro serviço de saúde que possa afetar sua pesquisa ou recebimento de serviços de saúde (a menos que o Assinante assuma total responsabilidade por essa decisão com base em seu caso de uso exclusivo e interações com seus Usuários, também como as possíveis implicações do uso de IA dessa maneira).
  2. O Assinante reconhece que, se estiver usando recursos de IA generativa da OpenAI, as saídas da OpenAI são geradas por computador e não por humanos e podem produzir saídas imprecisas. A Zendesk não garante a precisão desses resultados.
  3. O Assinante reconhece que, se uma saudação do bot do Zendesk for usada para fornecer uma mensagem de isenção de responsabilidade aos Usuários Finais do Assinante, a funcionalidade "Gerar variações" não será ativada para garantir a integridade do conteúdo da mensagem. 
  4. O Assinante reconhece que ativar a funcionalidade IA Generativa para Agentes/IA Generativa para Base de Conhecimento na Central de Administração ativará essa funcionalidade para todos os agentes em sua instância, independentemente de suas funções e permissões. 


      

Isenção de responsabilidade: Devido a alterações em leis ou regulamentos ou alterações no Serviço do Zendesk, as configurações de segurança neste documento podem mudar periodicamente. Este documento contém as recomendações da Zendesk para as configurações de segurança mínimas eficazes para a proteção de PHI nos produtos Zendesk descritos acima no momento. Este documento não constitui um modelo exaustivo para todos os controles sobre esses dados nem constitui aconselhamento jurídico. Cada assinante do Zendesk deve procurar sua própria assessoria jurídica com relação aos requisitos de conformidade com HIPAA e deve fazer alterações adicionais em suas configurações de segurança de acordo com a análise independente de cada assinante, desde que essas alterações não prejudiquem ou prejudiquem a segurança das configurações descritos neste documento.

 

Alterar registro de contas com HIPAA ativado:

 

10 de outubro de 2024

  • Adição da Seção I, Support, número 12 (CSAT) e edição da Seção I, Support, número 11 (CSAT legado) para acomodar a nova funcionalidade. 

7 de março de 2024

  • Seção X adicionada, Aviso sobre a funcionalidade de IA do Zendesk
  • Seção I, Support, número 7 (permissões de visualização):
    • Esclareceu que as "permissões de visualização" pertencem a uma "instância/marca/organização" inteira, e não apenas à "organização".
    • Adição de uma nova disposição para o comportamento específico da organização do usuário final. 
  • Seção I, Support, número 9 (e-mail):  
    • Expandiu as circunstâncias nas quais o Zendesk Support envia um email para um usuário final para incluir respostas pelo canal de email ou aquelas iniciadas por uma automação ou gatilho, em vez de apenas um agente respondendo a um ticket.
    • Especificou que, por padrão, as notificações automatizadas podem conter a correspondência de ticket mais recente ou outras informações configuradas, que podem incluir PHI.

 

25 de outubro de 2023

  • Introdução: Linguagem de introdução mais clara para contas com HIPAA ativado
  • Seção II, Guide e Gather, número 1 (Restrições da Central de Ajuda): substituição das restrições de IP por artigos restritos para esclarecimento

 

13 de abril de 2023

  • Seção I, Support, número 4 (APIs) : 
    • Link adicionado para os métodos de autenticação para fins de clareza 
    • b) Remoção das recomendações de período de tempo exato para rotação a fim de se alinhar às práticas recomendadas do setor e remoção da referência aos Termos de Serviço da REST API (redundância)
    • adicionou c) para avisar sobre o uso da autenticação básica para a API 
  • Seção II, Guide:
    • Número 1 (Restrições da Central de Ajuda): adição de referência a centrais de ajuda fechadas ou restritas para alinhamento com a funcionalidade do produto
    • Número 5 (@menções): Adicionada a opção de desativar @menções para alinhar com o produto funcionalidade 
  • Seção III, mensagens: 
    • Números 1 e 2 (canais de terceiros e anexos privados): adicionados identificadoresde seção (i) e (ii) para maior clareza
    • Número 2 (anexos privados): adicionado “URLs e/ou” para esclarecimento
    • Número 7-10 (autenticação do usuário final, exclusão de conversas do Answerbot, supressão, verificação de malware): seções completas adicionadas para fins de transparência
  • Seção IV, Sunshine Conversations: toda a seção foi adicionada devido ao Sunshine Conversations na Zendesk Suite se tornar parte do BAA 
  • Seção V, Chat, número 3 (Espaço de trabalho do agente): pequenas correções de frase
  • Seção VIII, aplicativos para dispositivos móveis, número 5-7 (verificação de malware, supressão, autenticação do usuário final): seções inteiras adicionadas para fins de transparência

24 de fevereiro de 2023

  • Seção I. Support, número 3: foi removida a distinção entre as restrições de IP do Support e do Chat, pois a interface do usuário agora está unificada.
  • Seção I. Support, número 5: esclarecimento adicional sobre falha no cumprimento do requisito 
  • Seção I. Support, número 7: "Assinante não deve" alterado para "Assinante não deve".
  • Seção IV. Chat, número 2: esclarece que toda a funcionalidade de exportação de dados do Chat usando e-mail é proibida e não está restrita apenas a transcrições e encaminhamentos. 
  • Seção III. mensagens: seção inteira adicionada à conta para a funcionalidade de mensagens do Zendesk, além do escopo do Business Associate Agreement da Zendesk.

9 de julho de 2021

  • Adiciona o ponto 3. na seção Chat para responsabilidades relacionadas ao uso do Espaço de trabalho do agente.

21 de janeiro de 2021

  • A adição do número 1.11 não permite o CSAT, a menos que o Assinante assuma a responsabilidade pelos dados enviados por email como parte da pesquisa. 
  • A ressalva no número 1.7 permite que os Assinantes alterem as permissões de visualização devido ao fato de os usuários já terem aprovação para acessar esses dados em suas extremidades.
  • Todo o documento foi atualizado para corresponder ao estilo da empresa de links incorporados no texto, em vez de URLs incorporados (sem impacto no conteúdo da configuração).

Agosto de 2020

  • Adição do Explore Enterprise, que abrange o aumento dos recursos de compartilhamento de painéis
  • Remoção do banimento de anexos do Chat (aborda agora os requisitos de autenticação do Support )
  • Desambiguação de que o banimento de ePHI em campos personalizados se aplicava especificamente ao uso do Insights e não globalmente
  • Adição de uma nova seção que aborda complementos para serviços implantados, com "Conversas paralelas" sendo a primeira adição
  • Várias edições de gramática/formatação (inconsequentes para o conteúdo)

13 de julho de 2020:

  • Desambiguação feita em relação ao uso de SMS pelo Serviço em oposição ao uso nativo de SMS para 2FA no produto. * Para evitar dúvidas, as advertências de dados relacionadas ao ePHI na seção 10 sobre SMS não se aplicam ao uso de 2FA no produto (conforme descrito na seção 1.a), pois essa funcionalidade envia apenas uma cadeia de caracteres numérica para verificação de identidade."

13 de dezembro de 2019 

  • permite que as restrições de IP do agente sejam removidas onde o caso de uso não permite essas restrições, desde que a MFA no acesso do agente seja aplicada.

17 de dezembro de 2019 

  • permite comentários de usuários finais no Guide, desde que os agentes moderem esses comentários e removam todas as PHI.

6 de novembro de 2019

  • Artigo atualizado para refletir a alteração de que os assinantes podem optar, a seu exclusivo critério, por abandonar ou substituir qualquer configuração específica, desde que assumam a responsabilidade por essa decisão.

"A falha do Assinante em implementar e cumprir qualquer configuração específica listada abaixo, ou qualquer série de configurações obrigatórias listadas abaixo, deve ser

risco do Assinante e a critério exclusivo do Assinante; e tal falha isentará a Zendesk e seus funcionários, agentes e afiliados de qualquer responsabilidade com relação a qualquer acesso não autorizado ou uso ou divulgação impróprios dos Dados de Serviço do Assinante, incluindo qualquer Informação de Saúde Protegida eletrônica, que resulte de tal falha pelo Assinante . "

  • Outras alterações incluem
    • 1. a capacidade de usar SMS, desde que o assinante assuma toda a responsabilidade por garantir que nenhuma PHI esteja presente em tais transmissões.
    • 2. A capacidade de usar anexos no Chat, desde que o assinante assuma toda a responsabilidade por garantir que nenhuma PHI esteja presente nesses anexos.

6 de março de 2019 

  • atualizado para incluir as configurações do Zendesk Explore

17 de janeiro de 2019

  •  atualizado para não permitir anexos no Chat.

 

Contas com HDS ativado:

Todos os termos em letras maiúsculas usados neste documento terão os significados atribuídos a eles no Anexo de Termos do HDS ao Contrato Principal de Assinatura da Zendesk ("Anexo de Termos do HDS").
A Zendesk e o Assinante firmaram esse Anexo de Termos do HDS, que exige que o Assinante implemente e cumpra as configurações a seguir para toda e qualquer Conta com HDS ativado antes de introduzir qualquer Informação Pessoal de Saúde ("PHI") nos Serviços. Todos os termos em letras maiúsculas usados neste documento devem ter os significados atribuídos a eles no Anexo de Termos do HDS.
A falha do Assinante em implementar e cumprir qualquer configuração específica listada abaixo, ou qualquer série de configurações obrigatórias listadas abaixo, será de responsabilidade do Assinante e a critério exclusivo do Assinante; e tal falha isentará a Zendesk e seus funcionários, agentes e afiliados de qualquer responsabilidade com relação a qualquer acesso não autorizado ou uso ou divulgação indevidos dos Dados de Serviço do Assinante, incluindo quaisquer Informações Pessoais de Saúde eletrônicas, resultantes de tal falha por parte do Assinante .
As configurações de segurança mínimas a seguir para o Zendesk Support devem ser implementadas e são reconhecidas no Anexo de termos do HDS para qualquer conta com HDS ativado:

 

As configurações de segurança mínimas a seguir para o Zendesk Support devem ser implementadas e são reconhecidas no Anexo de termos do HDS para qualquer conta com HDS ativado:

  1. Proteja a autenticação do agente por um dos dois métodos a seguir:
    1. Empregando o Zendesk Support nativo com configurações de senha: (i) definido como “Alto”; ou (ii) personalizado pelo Assinante de maneira que estabeleça requisitos não menos seguros do que os estabelecidos na configuração "Alta". Além disso, de acordo com a opção nesta subseção, o Assinante também deve ativar e aplicar a Autenticação de Dois Fatores ("2FA") nativamente dentro do Serviço; e os controles administrativos que permitem que os administradores definam senhas para os usuários finais devem ser desativados; ou
    2. Usar uma solução externa de Single Sign On (SSO") com requisitos estabelecidos não menos seguros do que os estabelecidos na configuração de senha "Alta" do Zendesk e ativar e aplicar a autenticação de dois fatores dentro da solução selecionada para o acesso de todos os agentes. Os controles administrativos que permitem que os administradores definam senhas para os usuários finais devem ser desativados.
    3. Todas as opções de autenticação que utilizam SSO como método de autenticação devem desativar o acesso por senha.
  2. A criptografia Secure Socket Layer ("SSL") nas contas com HDS ativado deve permanecer ativada o tempo todo. Contas com HDS ativado que utilizam um domínio diferente de zendesk.com devem estabelecer e manter SSL hospedado.
  3. O acesso do agente deve ser restrito a endereços IP específicos sob o controle do Assinante para Support e Chata menos que o Assinante habilite a autenticação multifator para agentes conforme descrito acima nos requisitos 1.a ou 1.b (nativamente dentro do Serviço ou dentro do ambiente do Assinante, juntamente com o Enterprise SSO).  Para evitar dúvidas, "Acesso de agente" deve denotar o acesso concedido a um agente humano que acessa os Dados de Serviço por meio da Interface do Usuário ("IU").
  4. Na medida em que a Conta Habilitada para HDS do Assinante permita chamadas para as Interfaces de Programação de Aplicativos do Zendesk ("APIs"), o Assinante assumirá toda a responsabilidade por entender as implicações de segurança de todas as entidades do Assinante ou de terceiros com permissão para criar, acessar, modificar ou apagar Dados de Serviço e PHI por meio desse acesso e/ou integrações. Para acessar essas APIs, o Assinante deve implementar as seguintes práticas recomendadas de segurança com base no modelo de API usado:
    1. Abordagem OAuth 2.0.  Esse modelo fornece os recursos de segurança mais granulares, mas requer que os direitos sejam aceitos por um usuário final.  Sempre que possível, o Assinante utilizará a abordagem e o esquema de autenticação OAuth 2.0. O Assinante dará a cada cliente OAuth uma função descritiva e exclusiva de Nome do Cliente e Identificador Exclusivo. As permissões concedidas para cada token OAuth devem permitir o mínimo de privilégios necessários para realizar as tarefas necessárias.
    2. Abordagem do token da REST API.  Esse modelo é o mais amplo e permite que um token da API utilize toda a funcionalidade do modelo da API.  Por sua natureza, ele fornece acesso e recursos mais amplos e deve ser usado com cautela. Ao usar essa abordagem, o Assinante (i) usará um token exclusivo para cada serviço e dará ao token um nome descritivo que designa a função; (ii) não compartilhar tokens da API com terceiros, a menos que seja razoavelmente necessário e de acordo com métodos de transmissão que são criptografados de ponta a ponta; (iii) reconhecer que, se o token da API for compartilhado com terceiros e o Assinante for informado de uma violação de dados de terceiros, o Assinante alternará o token associado imediatamente; e (iv) alterne o token, no mínimo, uma vez a cada cento e oitenta (180) dias.  O Assinante deve seguir os Termos de Serviço da REST API do Serviço. 
  5. O assinante deve ativar a opção "Solicitar autenticação para download" para solicitar autenticação para acessar os anexos.
  6. O Assinante deve aplicar sistematicamente, em todos os pontos de extremidade acessados por Agentes, Administradores e Proprietários, um protetor de tela bloqueado por senha ou uma tela de inicialização configurada para interagir com, no máximo, quinze (15) minutos de inatividade do sistema.
  7. O Assinante não deve alterar as permissões de visualização que permitem que um usuário veja atualizações de uma organização inteira ou alterar a configuração padrão que permite o acesso além dos tickets do próprio usuário (a menos que o Assinante assuma toda a responsabilidade por garantir que esses usuários sejam aprovados pelo Assinante para acessar todos os dados subsequentes).
  8. O Assinante reconhece que a Zendesk não é responsável por proteger as transmissões de e-mail dos Usuários Finais e os Dados de Serviço relacionados antes de serem recebidos na instância do Zendesk Support do Assinante. Isso inclui qualquer PHI que possa ser transmitida por e-mail por meio de respostas aos tickets do Zendesk Support , incluindo, entre outros, comentários ou anexos do ticket.
  9. O Assinante reconhece que o Zendesk Support envia um e-mail para um Usuário Final quando um Agente do Assinante responde a um ticket do Zendesk Support .  Por padrão, esse e-mail contém toda a correspondência que o agente enviou de volta ao usuário final e pode incluir PHI. Para proteger ainda mais o Assinante, sua instância do Zendesk Support deve ser configurada para alertar apenas o Usuário Final de que um Agente respondeue solicitar que o Usuário Final se autentique no Zendesk Support para ver o conteúdo da mensagem.
  10. O Assinante reconhece que qualquer funcionalidade de mensagem de texto utilizada a seu exclusivo critério em qualquer Serviço da Zendesk é sustentada por SMS e/ou protocolos relacionados, que podem envolver a transmissão não criptografada de mensagens enviadas para ou fora do(s) Serviço(s).  Como tal, a funcionalidade de mensagem de texto deve:
    1. não pode ser usado em uma conta com HDS ativado* ou
    2. se usado, o Assinante assume toda a responsabilidade pelo uso de tal funcionalidade.

* Para evitar dúvidas, as advertências de dados relacionadas ao ePHI na seção 10 sobre SMS não se aplicam ao uso de 2FA no produto (conforme descrito na seção 1.a), pois essa funcionalidade envia apenas uma cadeia de caracteres numérica para verificação de identidade.

As configurações de segurança mínimas a seguir para os serviços do Zendesk Guide e Gather devem ser implementadas e são reconhecidas no Anexo de termos do HDS para qualquer conta com HDS ativado:

  1. O Assinante reconhece que os Serviços do Guide e Gather são públicos por natureza (não aproveitando as restrições de IP para centrais de ajuda "internas") e, portanto, o Assinante deve garantir que quaisquer artigos no Zendesk Guide ou no Serviço Gather não incluam PHI, seja por meio do texto dos artigo ou como anexo ou imagem dentro do artigo.
  2. O Assinante deve desativar a capacidade de os Usuários Finais adicionarem comentários no Zendesk Guide ou deve moderar e assumir a responsabilidade pela remoção de PHI de todos os comentários.
  3. O uso de “Moderadores da comunidade” que não sejam funcionários do Assinante não será permitido no Serviço Gather.

As configurações de segurança mínimas a seguir para o serviço do Zendesk Chat devem ser implementadas e são reconhecidas no Anexo de termos do HDS para qualquer conta com HDS ativado:

  1. O Assinante deve limitar o acesso dos Agentes ao Serviço do Zendesk Chat e autenticando pelo Serviço do Zendesk Support .
  2. O assinante deve desativar o encaminhamento de e-mail.
  3. O Assinante não deve ativar os "Espaços de trabalho do agente", a menos que assuma total responsabilidade por garantir (i) que nenhum ePHI esteja presente nos Chats e/ou (ii) que todos os Agentes tenham permissão para visualizar esses dados.

As configurações de segurança mínimas a seguir para o uso do Serviço do Zendesk Explore devem ser implementadas e são reconhecidas no Anexo de termos do HDS para qualquer conta com HDS ativado:

O Assinante reconhece que as ePHI podem ser exibidas no produto Explore por meio de nomes de usuário, títulos de ticket, opções de campo e formulário e qualquer conteúdo encontrado em campos de texto de formato livre.

  1. Para quaisquer instâncias de Serviço no escopo que contenham PHI, o Assinante deverá (i) conceder acesso à interface do Explore apenas aos agentes que puderem acessar todos os tickets/chamadas/chats que possam conter PHI nas instâncias de Serviço pai e (ii) concederá esse acesso levando em consideração o mínimo de privilégios necessários para o uso do Explore em seu ambiente. Para obter mais informações sobre a configuração de níveis de acesso no Explore, consulte aqui.
  2. Ao aproveitar a funcionalidade de "exportação", (i) o Assinante reconhece que as PHI podem ser transferidas para o dispositivo permitido pelo Assinante para acessar a interface do agente e todos os controles de atendimento nesses dispositivos são de responsabilidade do Assinante e (ii) o Assinante deve negar o uso da funcionalidade de exportação nativa por e-mail para os referidos relatórios exportados, a menos que assuma a responsabilidade de (a) garantir que nenhuma PHI esteja contida nessas exportações ou (b) que os serviços de e-mail usados para essas transferências possam acomodar a criptografia por meio do protocolo de criptografia mínimo permitido pelos padrões PCI então vigentes.

* Considerações especiais para o uso do Explore Enterprise:

O Assinante reconhece que o uso do Serviço Explore Enterprise pode implicar em mais recursos de compartilhamento e exportação de dados. O Assinante deve:

  1. (i) garantir que não existam ePHI nesses painéis e/ou (ii) compartilhar painéis apenas com agentes, grupos, listas ou usuários finais aprovados para visualizar e receber esses dados.
  2. aproveitar restrições de IP
  3. ao compartilhar painéis por URL (Uniform Resource Locator), o Assinante reconhece que, em vez de compartilhar com contas de usuários individuais ou em grupo, os dados devem ser compartilhados por um link de acesso. Portanto, o Assinante deve (i) ativar a proteção por senha, (ii) garantir que a complexidade, a rotação, o armazenamento e a distribuição das senhas escolhidas para a parte destinatária estejam em conformidade com as políticas de senha do Assinante para a proteção dos dados contidos nesses painéis e (iii) seja alternado sem demora indevida após a suspeita ou confirmação da exposição

As configurações de segurança mínimas a seguir para o uso dos aplicativos móveis do Zendesk (ou acesso feito por dispositivos móveis, como smartphones ou tablets) devem ser implementadas e são reconhecidas na Exposição de termos do HDS para qualquer conta com HDS ativado:

  1. O uso deve incluir criptografia no nível do dispositivo
  2. O acesso biométrico ou PIN definido para a configuração de dispositivo mais alta permitida deve ser aproveitado
  3. As notificações que permitem que os comentários do ticket sejam exibidos nas telas de bloqueio desses dispositivos serão desativadas
  4. Os bloqueios por inatividade de tela devem ser ativados e configurados para serem bloqueados a não mais de 15 minutos de inatividade.

Aviso sobre a funcionalidade no produto para serviços associados implantados (“Complementos”):

  1. Serviço associado implantado do Collaboration: “Conversas paralelas”. O Assinante reconhece que o uso da funcionalidade de "Conversas paralelas" pode resultar na criação de mensagens de "ticket dependente" ou "Conversas paralelas" dentro ou enviadas da instância de Support do Assinante para destinatários por ticket, email, Slack ou integrações (a critério do Agente). Se o Assinante optar por usar essa funcionalidade em uma Conta Habilitada para HDS, o Assinante assumirá toda e qualquer responsabilidade por (i) garantir que nenhuma PHI esteja presente em tais mensagens ou (ii) se PHI puder estar presente em mensagens, o Assinante é o único responsável por qualquer responsabilidade, custo, dano ou dano relacionado à aquisição, acesso, uso ou divulgação não autorizados de PHI resultantes da troca de mensagens por meio da funcionalidade “Conversas paralelas”.

Isenção de responsabilidade: Devido a alterações em leis ou regulamentos ou alterações no Serviço do Zendesk, as configurações de segurança neste documento podem mudar periodicamente. Este documento contém as recomendações da Zendesk para as configurações de segurança mínimas eficazes para a proteção de PHI nos produtos Zendesk descritos acima no momento. Este documento não constitui um modelo exaustivo para todos os controles sobre esses dados nem constitui aconselhamento jurídico. Cada assinante do Zendesk deve procurar sua própria assessoria jurídica com relação aos requisitos de conformidade com o HDS e deve fazer alterações adicionais em suas configurações de segurança de acordo com a análise independente de cada assinante, desde que essas alterações não anulem ou prejudiquem a segurança das configurações descritos neste documento.

Aviso sobre a tradução: este artigo foi traduzido por um software de tradução automática para oferecer a você uma compreensão básica do conteúdo. Medidas razoáveis foram tomadas para fornecer uma tradução precisa, no entanto, a Zendesk não garante a precisão da tradução.

Em caso de dúvidas relacionadas à precisão das informações contidas no artigo traduzido, consulte a versão oficial do artigo em inglês.

Powered by Zendesk