¶ Perguntas e respostas
01O que é uma fonte de dados autoritativa?
É o sistema considerado como origem oficial dos dados cadastrais dos colaboradores, normalmente um sistema de RH ou ERP. O Corpia IGA utiliza essa fonte para apoiar os processos de gestão de identidades e acessos.
02Quais formas de integração são suportadas?
Os dados podem ser disponibilizados por API, Web Service, banco de dados ou arquivo texto, conforme a tecnologia disponível e o escopo definido durante o projeto.
03Quem deve participar da definição da integração?
Recomenda-se envolver as equipes responsáveis pelo sistema de origem, infraestrutura, segurança, identidade e negócio. A definição conjunta ajuda a validar dados, responsabilidades e critérios de operação.
04Quais dados organizacionais são necessários para colaboradores ativos?
A integração prevê dados de empresa, unidade, cidade, departamento, centro de custo e cargo. Cada informação deve possuir um identificador e uma descrição consistentes.
05Quais dados pessoais e funcionais são necessários?
São previstos CPF, matrícula e nome completo. A matrícula ou o CPF do superior imediato também é necessário para representar a relação de gestão.
06Telefone, celular e ramal são obrigatórios?
Não. Esses campos são opcionais e podem ser disponibilizados quando fizerem parte do escopo da integração.
07O que é posto de trabalho?
É um agrupamento de características associadas a uma posição na organização, podendo considerar empresa, unidade, local, centro de custo e cargo. Esse campo é opcional e pode ser numérico ou textual.
08Como o CPF deve ser enviado?
O CPF deve ser enviado como texto no formato XXX.XXX.XXX-XX, conforme a especificação de integração.
09A matrícula pode conter letras?
Sim. Para colaboradores ativos, a matrícula pode ser disponibilizada como número ou texto, conforme o padrão adotado pela organização.
10Como o superior imediato deve ser identificado?
A relação de superior imediato deve ser informada pela matrícula ou pelo CPF do gestor, de acordo com o identificador definido para a integração.
11O que deve ser validado antes de ativar a integração?
Devem ser verificados o preenchimento dos campos obrigatórios, os tipos de dados, a formatação, a unicidade dos identificadores e a coerência das relações organizacionais.
12Como um colaborador ativo é identificado?
O registro ativo deve apresentar os dados obrigatórios definidos para a integração, incluindo os identificadores pessoais, funcionais e organizacionais necessários para localizar corretamente a identidade.
13O que acontece quando os dados organizacionais mudam?
As alterações disponibilizadas pela fonte autoritativa podem ser utilizadas pelos processos configurados no Corpia IGA. O efeito exato depende das regras e automações previstas no projeto.
14Como evitar registros duplicados?
A fonte deve manter identificadores consistentes e únicos. Antes do envio, recomenda-se validar possíveis duplicidades de matrícula, CPF e demais chaves utilizadas na integração.
15Quais dados são necessários para informar um desligamento?
A especificação prevê matrícula, CPF e data de desligamento. O nome do colaborador pode ser enviado, mas não é obrigatório para esse conjunto de dados.
16Como deve ser enviada a data de desligamento?
A data deve ser disponibilizada em um campo do tipo data, de forma válida e consistente com o padrão acordado para a integração.
17O que pode ocorrer após a identificação de um desligamento?
Conforme a configuração adotada, uma rotina pode converter a caixa postal em compartilhada e remover licenças atribuídas. Outras ações dependem do escopo e das regras definidas para o ambiente.
18Por que é importante manter os dados de desligamento corretos?
Esses dados são usados para identificar o momento e a identidade envolvidos no processo. Informações incorretas ou duplicadas podem exigir análise antes da execução das automações.
19O que é uma Shared Mailbox?
É uma caixa postal configurada como compartilhada no Exchange Online. Na rotina documentada, a conversão é utilizada no processo de desligamento antes da remoção das licenças atribuídas ao usuário.
20Qual é a finalidade da conversão para Shared Mailbox?
A rotina foi definida para apoiar o desligamento de colaboradores, convertendo a caixa postal para o tipo compartilhado e removendo as licenças atribuídas.
21Quais componentes são necessários para a rotina de conversão?
A documentação prevê módulo Exchange Online Management versão 3 ou superior, permissões administrativas adequadas, acesso ao Active Directory local e conectividade com Microsoft Graph e Exchange Online.
22Como funciona o fluxo geral da rotina?
A rotina localiza o usuário no diretório, obtém seu identificador principal, converte a caixa no Exchange Online, consulta as licenças no Microsoft Graph e solicita a remoção das licenças encontradas.
23A conversão e a remoção de licenças são a mesma operação?
Não. A conversão da caixa é executada no Exchange Online, enquanto a consulta e a remoção das licenças são realizadas por meio do Microsoft Graph.
24O que ocorre se o usuário não for localizado?
A rotina registra uma mensagem informando que o usuário não foi encontrado. Nesse cenário, os dados de entrada e a existência da identidade na origem devem ser verificados pela equipe responsável.
25É possível integrar informações de férias e afastamentos?
Sim. Esse conjunto de dados é opcional e pode ser fornecido quando fizer parte do escopo da integração.
26Quais campos são previstos para férias e afastamentos?
São previstos matrícula, CPF, data de saída e data de retorno. O motivo do afastamento é opcional.
27A data de retorno é obrigatória?
Sim. Quando o conjunto opcional de férias e afastamentos for utilizado, as datas de saída e retorno fazem parte dos campos obrigatórios.
28A rotina mantém histórico de execução?
Sim. A documentação prevê registro das ações em arquivo de log, permitindo acompanhar resultados e mensagens de falha.
29Quais informações devem ser observadas no log?
Devem ser observados o usuário processado, a ação executada, a mensagem retornada e, quando houver falha, o motivo e a linha identificada pela captura de erro.
30O que significa uma mensagem FATAL?
Indica uma falha crítica capturada durante a execução. A mensagem detalhada deve ser encaminhada à equipe técnica responsável, sem incluir credenciais ou outros dados secretos.
31O que significa Invalid client secret?
A mensagem indica um problema com a credencial utilizada na autenticação, como um segredo inválido ou expirado. A correção deve ser realizada por um administrador autorizado.
32O que significa Unauthorized?
Indica que a identidade utilizada não possui autorização suficiente para executar a operação. As permissões configuradas devem ser revisadas por um administrador autorizado.
33O que significa User not found?
Indica que o usuário não foi localizado na origem consultada. Verifique os identificadores informados, a existência do registro e a disponibilidade da fonte de dados.
34Como tratar alertas de versão do Node.js?
O log analisado apresentou avisos de incompatibilidade entre a versão do Node.js e requisitos de alguns pacotes. A equipe técnica deve validar a matriz de compatibilidade antes de atualizar o runtime ou as dependências.
35O que fazer quando o npm informa vulnerabilidades?
O alerta deve ser analisado pela equipe técnica. Correções automáticas com alterações incompatíveis não devem ser aplicadas diretamente em produção sem avaliação, testes e plano de reversão.
36Como confirmar que as migrações do banco foram executadas?
Verifique a saída do processo de migração. Registros de conclusão para cada migração indicam que aquela etapa foi processada. Em caso de erro, preserve o log e acione a equipe técnica.
37Como confirmar que as cargas iniciais foram executadas?
Verifique a saída do processo de carga inicial e confirme os registros de conclusão. Qualquer falha deve ser analisada antes da liberação do ambiente.
38Alterações podem ser testadas diretamente em produção?
Não é recomendado. A documentação orienta testar alterações em uma cópia separada, executar manualmente com um usuário de teste e verificar o log antes da publicação em produção.
39Quais dados nunca devem ser publicados em uma FAQ?
Não publique segredos, tokens, credenciais, identificadores de aplicações ou ambientes, domínios internos, caminhos de servidores, dados pessoais, nomes de clientes, tickets, matrículas ou informações de desligamento individualizadas.
40Posso anexar um log completo em um chamado?
Antes do compartilhamento, remova ou masque credenciais, tokens, dados pessoais, nomes de ambientes, caminhos internos e quaisquer informações que não sejam necessárias ao diagnóstico.
41O que enviar ao suporte para análise?
Informe uma descrição objetiva do cenário, etapa em que ocorreu a falha, data e horário aproximados e a mensagem de erro sanitizada. Não envie senhas, segredos ou dados pessoais desnecessários.
Revise o termo pesquisado ou selecione outra categoria.