> ## Documentation Index
> Fetch the complete documentation index at: https://docs.strattum.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Gerencie acessos e fontes do Anywhere

> Disponibilize aplicações e fontes e configure as fichas contextuais conforme a ontologia de cada cliente.

O acesso ao Anywhere combina identidade, aplicações disponíveis e permissões sobre as fontes. Configure essas partes antes de orientar o usuário a conectar a extensão.

## Separe as responsabilidades

| Camada | Responsável | O que precisa estar preparado |
| - | - | - |
| Identidade Strattum | Administrador de identidade | Conta e autenticação no ambiente |
| Aplicação e domínio | Administrador da plataforma | Conta da aplicação integrada reconhecida e origem HTTPS autorizada |
| Conector administrativo | Responsável pela fonte | Credenciais, recursos e sincronização |
| Vínculo individual | Usuário, quando solicitado | Conta da pessoa na fonte |
| Permissão sobre os dados | Administrador da fonte e da plataforma | Dados que aquela pessoa pode consultar |

O sucesso no login identifica a pessoa. A disponibilidade das operações e das informações depende das demais camadas.

## Como o Gateway identifica as aplicações

No fluxo conectado à plataforma, o Gateway consulta as fontes disponíveis à pessoa no Identity e os metadados dos conectores no Catalog.

Ele usa os domínios cadastrados para identificar as contas das aplicações suportadas. O domínio também é associado ao conector que disponibilizou os dados.

O Zendesk é a primeira integração disponível. Para uma conta dessa aplicação, confira:

1. O conector tem o tipo Zendesk e está disponível para a pessoa.
2. Os metadados contêm a origem HTTPS da conta, como `https://empresa.zendesk.com`.
3. A origem corresponde ao domínio em que a pessoa atende.
4. O domínio identifica uma única conta de conector na descoberta.

Em **Configurações → Conta**, a pessoa pode consultar as origens recebidas. Em **Aplicações → Zendesk**, o subdomínio é apresentado para consulta.

## Políticas explícitas de acesso

O Gateway também aceita um arquivo administrativo indicado por `ANYWHERE_POLICY_FILE`. Quando utilizado, ele define as aplicações e os domínios acessíveis por esse caminho, em vez da descoberta dinâmica da plataforma.

> **Referência técnica de uma política explícita**
>
> O exemplo abaixo é para instalações que utilizam esse arquivo. Substitua domínio, identificador de conector e identificador de usuário pelos valores do ambiente.
>
> ```json theme={null}
> {
>   "entitlement": "grants",
>   "applications": [
>     {
>       "name": "zendesk",
>       "origins": ["https://empresa.zendesk.com"],
>       "object_types": ["ticket"],
>       "connectors": [
>         {
>           "origin": "https://empresa.zendesk.com",
>           "connector_id": "identificador-do-conector"
>         }
>       ]
>     }
>   ],
>   "grants": [
>     {
>       "user_id": "identificador-do-usuario",
>       "origins": ["https://empresa.zendesk.com"]
>     }
>   ]
> }
> ```
>
> | Campo | Significado |
> | - | - |
> | `entitlement: grants` | Restringe o uso às pessoas e origens listadas em `grants` |
> | `entitlement: authenticated` | Permite aos usuários autenticados utilizar as aplicações declaradas, sujeitos às permissões dos dados |
> | `applications` | Declara a aplicação, os domínios e os tipos de objeto |
> | `connectors` | Relaciona cada domínio ao conector que disponibiliza seus dados |
> | `user_id` | Identificador da pessoa no serviço de identidade; use o identificador, não o e-mail |
> | `origins` | Lista de origens HTTPS exatas autorizadas |
>
> No modo `grants`, uma lista vazia não habilita pessoas. No modo `authenticated`, omita a lista de concessões. O arquivo é lido na inicialização; reinicie o serviço pelo procedimento operacional da instalação após uma alteração.

## Disponibilize as fontes

O conector administrativo disponibiliza dados da fonte para a plataforma. A vinculação individual informa a identidade da pessoa naquela fonte, quando exigida pela política.

| Preparação | O que conferir |
| - | - |
| Credenciais administrativas | Acesso da integração aos recursos necessários |
| Recursos selecionados | Registros e conteúdos necessários ao trabalho na aplicação integrada |
| Sincronização | Execução concluída e atualização dos recursos selecionados |
| Disponibilidade no Company Brain | Processamento e disponibilização dos dados para consulta |
| Permissões individuais | A pessoa alcança as fontes e os registros esperados |

Confira os recursos selecionados na integração. No Zendesk, por exemplo, disponibilizar o ticket e disponibilizar seus comentários são escolhas de dados distintas. O uso do histórico depende de essas informações estarem disponíveis para consulta.

Para disponibilizar a fonte no ambiente da equipe, ative o conector pelo Console, conforme o [Quickstart de Data Pipelines](https://docs.strattum.ai/data-pipelines/quickstart). O guia do [conector Zendesk](https://docs.strattum.ai/data-pipelines/connectors/zendesk.md) é a referência para desenvolvimento local. Para a vinculação feita pelo usuário, encaminhe [Conecte suas fontes](https://docs.strattum.ai/applications/anywhere/connections.md).

## Configure as fichas para a ontologia do cliente

As fichas são configuradas conforme a necessidade do cliente e a ontologia da sua implantação BYOC. A ontologia define os tipos de registro, seus atributos e seus relacionamentos; a configuração das fichas define o que a equipe consulta a partir desse modelo.

Os campos, indicadores, períodos e relacionamentos não são uma lista fixa do Anywhere. Eles precisam corresponder ao modelo e aos dados disponíveis naquele ambiente.

A personalização deve manter as informações relacionadas à aplicação de origem e à conta que gerou o contexto. Na integração atual, a ficha aberta a partir de um ticket deve manter a relação com o Zendesk correspondente.

| Dependência | Finalidade |
| - | - |
| `ANYWHERE_MEMORY_API_URL` e `ANYWHERE_SKILLS_API_URL` | Endereços usados pelo Gateway nas consultas estruturadas |
| Associação entre domínio e conector | Identificar a aplicação e a conta de origem dos registros |
| Registro e relacionamento de entrada | Resolver o assunto da ficha a partir do registro aberto |
| Tipos, atributos e relações da ontologia | Definir os dados e caminhos de navegação da ficha |
| Registros relacionados | Apresentar listas e indicadores coerentes com o contexto de origem |
| Permissões sobre as fontes | Limitar os dados visíveis para a pessoa |

As definições de referência do Zendesk apresentam fichas de pessoa e organização. Elas servem de base para uma implantação cuja ontologia seja compatível. Se a ontologia ou a necessidade do cliente for diferente, ajuste a configuração da implantação.

Ao ajustar uma ficha, confira os rótulos, relacionamentos, períodos e listas apresentados. Um indicador de **90 dias** e uma lista ordenada por data são informações diferentes. Veja o [exemplo de fichas do Zendesk](https://docs.strattum.ai/applications/anywhere/zendesk/context-views.md).

### Personalização por implantação

O Gateway permite um diretório de configuração próprio do cliente indicado por `ANYWHERE_CONTEXT_VIEWS_CUSTOM_DIR`. A estrutura separa os arquivos por aplicação e por ficha, por exemplo `zendesk/person-overview.yaml`.

| Parte da configuração | Responsabilidade |
| - | - |
| `definition` | Seções, rótulos, ordem e ações apresentadas |
| `bindings` e consultas | Relações, atributos, filtros e períodos utilizados para obter os dados |
| Diretório por aplicação | Separação das fichas conforme a integração de origem |

A configuração do cliente prevalece por ficha, mantendo o padrão do produto separado. Uma personalização pode ajustar os vínculos com a ontologia e manter a apresentação de referência quando ela atende à necessidade da equipe.

Confira cada configuração contra a ontologia ativa e teste a navegação a partir de um registro real da aplicação. A configuração das fichas não é uma preferência individual do usuário da extensão.

## Histórico e mudanças de autorização

O Gateway compara as informações verificadas de autorização recebidas no login e nas renovações da sessão. Enquanto elas permanecerem iguais, a conversa reutiliza seu contexto interno, incluindo resultados de ferramentas e resumos do Applications Runtime.

Uma mudança detectada invalida as conversas internas de chat e rascunho. O próximo uso estabelece o contexto atual, mantendo a abertura conhecida pela extensão. O serviço bloqueia seleções antigas e resultados que perderam validade durante a geração.

### O que esse reinício protege

| Situação | Comportamento |
| - | - |
| Renovação com as mesmas informações de autorização | Preserva o contexto, sem aviso de reinício |
| Mudança de autorização observada na renovação | Reinicia o contexto interno e informa a pessoa no próximo resultado apresentável |
| Perda de habilitação para a aplicação ou a origem | Recusa a operação conforme a política vigente |
| Resposta antiga selecionada para atualizar um rascunho | Recusa antes de consultar o Runtime |
| Texto já exibido, editado ou inserido | Pode permanecer na interface e na aplicação de origem |

O reinício não cria uma configuração nova para o usuário ou uma opção de retenção. O editor e as versões locais continuam sob controle da extensão; o Gateway bloqueia a reutilização automática de threads e seleções antigas, sem comprovar a origem de todo texto enviado pela pessoa.

### Limites de ACL e retenção

A comparação acompanha as informações de autorização da conta, também chamadas **claims**. Ela não consulta todas as ACLs de documentos a cada pergunta. Uma alteração apenas na ACL da fonte pode deixar informações recuperadas anteriormente no contexto até seu reinício. Novas consultas continuam sujeitas ao acesso vigente.

A detecção depende da renovação normal da credencial e da atualização das informações fornecidas pelos serviços. Evite estabelecer um prazo fixo de detecção de revogações a partir da duração do token.

Reiniciar o contexto ou limpar o painel não exclui automaticamente o histórico persistido no Runtime. A proteção descrita aqui pertence aos fluxos do Gateway; uma integração que chama o Runtime diretamente não recebe essa comparação e esse reinício.

## Confira a entrega por perfil

Use uma conta de usuário com as permissões previstas na aplicação de origem para conferir o percurso, além da conta administrativa.

* A pessoa recebe os domínios e fontes previstos.
* A fonte que exige vínculo oferece **Conectar**.
* O vínculo correto apresenta **Conectado como**.
* As fichas refletem a necessidade e a ontologia do cliente e mantêm a relação com a aplicação de origem.
* Os dados recentes estão disponíveis após a sincronização.
* Duas perguntas com a mesma autorização continuam a conversa; uma renovação sem mudança preserva o contexto.
* Uma mudança de autorização observada reinicia o contexto, mantém o registro aberto e impede atualizar o rascunho com uma seleção anterior.
* O teste distingue permissões de documentos das informações de autorização da conta e confirma que perder acesso à aplicação continua sendo uma recusa.
* As preferências e os destinos disponíveis na integração estão configurados conforme o procedimento de trabalho; no Zendesk, confira também notas internas e destinos público e interno.

## Próximos passos

> **[Disponibilize o Anywhere](https://docs.strattum.ai/admin/anywhere/deployment.md)**
>
> Confira Gateway, identidade e o percurso de entrega à equipe.

> **[Fichas para o usuário](https://docs.strattum.ai/applications/anywhere/context-views.md)**
>
> Compartilhe a explicação do botão mais e das informações apresentadas.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.