Antes de lançar a Daya para toda a empresa, o responsável pelo setup deverá configurar o sistema para inserir informações essenciais como colaboradores, unidades, equipes e a personalização do dashboard.
Além do cadastro manual e do upload de planilha, clientes do plano Impacto têm a opção de habilitar SSO e Provisionamento SCIM, integrando a Daya ao Identity Provider (IdP) corporativo.
A Daya é compatível com qualquer IdP que siga os padrões SAML 2.0 e SCIM 2.0.
Esta documentação inclui exemplos para Okta e Microsoft Entra ID (antigo Azure AD), mas os mesmos princípios se aplicam a outros IdPs.
Como SSO e SCIM trabalham juntos?
SSO (SAML)
Integração de login único via SAML 2.0, conectando a Daya ao IdP do cliente. Com o Just-In-Time Provisioning (JIT), o registro do colaborador é criado automaticamente na primeira vez que ele faz login via SSO, sem necessidade de cadastro manual ou upload de planilha.
Dados básicos como nome, sobrenome e e-mail são importados do IdP. Após o login, o colaborador é redirecionado para o fluxo de onboarding da Daya, onde preenche informações específicas da plataforma (minha equipe, minha unidade, minhas causas e minhas habilidades) que não vêm do IdP.
Provisionamento SCIM
O JIT do SSO não resolve um cenário crítico: o desligamento de colaboradores.
Quando um colaborador sai da empresa, o JIT não tem como saber e o registro continua ativo na Daya.
O SCIM automatiza isso. Em vez de esperar o colaborador fazer login, o SCIM atualiza os registros na Daya conforme os dados mudam no IdP:
Os colaboradores aparecem na página de Gerenciamento de Colaboradores quando são atribuídos à aplicação Daya no IdP
Atualizações de dados (nome e sobrenome) sincronizam automaticamente
Colaboradores desativados no IdP perdem acesso à Daya imediatamente, com histórico preservado para auditoria
Pré-requisitos e regras de combinação
O SCIM não é obrigatório para usar SSO
O SSO é pré-requisito para o SCIM
O mesmo IdP deve ser usado para ambas as funções
Mesmo com SSO e SCIM habilitados, administradores continuam gerenciando níveis de acesso dentro da Daya
Mesmo com SSO e SCIM habilitados, colaboradores ainda precisam completar o onboarding após o primeiro login
Antes de começar
Você vai precisar de:
Acesso administrativo ao IdP da empresa
Permissão para criar uma nova aplicação corporativa no IdP
Permissão de Gestor de Empresa na Daya
Passo 1. Configurar o SSO (SAML)
1.1 Crie uma aplicação SAML no IdP
Crie uma nova integração do tipo SAML 2.0 no painel do IdP. Use os valores que aparecem na tela "SSO e Provisionamento SCIM" da Daya nos campos correspondentes do seu IdP.
No Okta:
Single Sign-On URL: cole o valor de "Reply URL (ACS URL)" da Daya
Audience URI (SP Entity ID): cole o valor de "Identifier (Entity ID)" da Daya
Name ID format: EmailAddress
Application username: Email
No Microsoft Entra ID:
Identifier (Entity ID): cole o valor de "Identifier (Entity ID)" da Daya
Reply URL (Assertion Consumer Service URL): cole o valor de "Reply URL (ACS URL)" da Daya
Sign on URL: deixe em branco
Logout URL: deixe em branco
1.2 Configure os atributos SAML
A Daya precisa receber três atributos na assertion SAML para criar ou atualizar colaboradores. Os nomes dos atributos enviados pelo IdP precisam ser exatamente:
emailfirstNamelastName
Esses nomes são case-sensitive e devem bater com os Required Attributes configurados na Daya.
No Okta (aba Sign On, Attribute Statements):
email=user.profile.emailfirstName=user.profile.firstNamelastName=user.profile.lastName
No Microsoft Entra ID (Single sign-on, Attributes & Claims, Edit):
Remova as claims padrão e adicione três novas claims:
email=user.mail(namespace em branco)firstName=user.givenname(namespace em branco)lastName=user.surname(namespace em branco)
1.3 Configure a tela de SSO da Daya
Na tela "SSO e Provisionamento SCIM" da Daya, preencha:
Required Attributes, E-mail:
emailRequired Attributes, Nome:
firstNameRequired Attributes, Sobrenome:
lastNameIdP Metadata URL: URL de metadata do seu IdP
Domínio do e-mail: domínio corporativo da empresa (exemplo:
suaempresa.com)
Onde encontrar a Metadata URL:
No Okta: aba Sign On da aplicação SAML, seção Metadata URL
No Microsoft Entra ID: SAML Signing Certificate, copie o valor de "App Federation Metadata Url"
Clique em Salvar Informações.
1.4 Atribua os colaboradores no IdP
Atribua os colaboradores que devem ter acesso à Daya à aplicação SAML que você criou.
No Okta: aba Assignments, Assign, Assign to People
No Microsoft Entra ID: Users and groups, Add user/group
Importante: Apenas colaboradores atribuídos no IdP conseguem acessar a Daya via SSO.
Passo 2. Configurar o Provisionamento SCIM
O SCIM é opcional, mas altamente recomendado para clientes que querem automatizar o ciclo completo de gestão de colaboradores (criação, atualização e desativação).
2.1 Habilite SCIM na mesma aplicação do IdP
Use a mesma aplicação que você criou no Passo 1, não crie uma nova.
No Okta: aba Provisioning, configure SCIM
No Microsoft Entra ID: aba Provisioning da aplicação, Get started, modo Automatic
2.2 Configure a conexão SCIM
Use os valores da seção "Provisionamento SCIM" na tela da Daya:
Endpoint SCIM base: copie do campo "Base URL" da Daya
Tipo de autenticação: Bearer Token via HTTP Header
Token de autenticação: copie do campo "OAuth Bearer Token" da Daya
Identificador único de usuário:
email
No Okta (Provisioning, Integration, Edit):
SCIM connector base URL: cole o valor de "Base URL" da Daya
Unique identifier field for users:
emailAuthentication Mode: HTTP Header
Authorization:
Bearerseguido do token (exemplo:Bearer eyJhbGc...)
No Microsoft Entra ID (Provisioning, Admin Credentials):
Tenant URL: cole o valor de "Base URL" da Daya
Secret Token: cole o token sem o prefixo Bearer, o Entra ID adiciona automaticamente
2.3 Habilite as operações SCIM
No Okta (Provisioning, To App, Edit):
Marque Create Users
Marque Update User Attributes
Marque Deactivate Users
No Microsoft Entra ID (Provisioning, Mappings):
Mantenha o mapeamento padrão "Provision Microsoft Entra ID Users"
Edite o mapeamento para garantir que
mail,givenNameesurnameestão sendo enviadosEm Provisioning Status, mude para "On"
2.4 Teste a conexão
Use a função de teste do IdP para validar a integração.
No Okta: Test Connector Configuration
No Microsoft Entra ID: Test Connection
Se tudo estiver correto, você verá uma mensagem de sucesso.
2.5 Atribua os colaboradores
Atribua os colaboradores que devem ter acesso à Daya à aplicação no IdP. Eles serão criados automaticamente na Daya em alguns segundos, com status Pendente até completarem o onboarding.
Comportamento esperado em cada cenário
Atribuir um colaborador no IdP:
Colaborador aparece automaticamente na página de Colaboradores na Daya
Status inicial: Pendente (até completar o onboarding)
Colaborador pode logar via SSO imediatamente
Atualizar dados no IdP (nome, sobrenome):
Mudanças sincronizam para a Daya em segundos
Dados específicos da Daya (causas, habilidades, equipe) não são afetados
Remover colaborador do IdP:
Acesso à Daya é revogado imediatamente
Colaborador some da lista de colaboradores na empresa
Histórico de atividades e métricas de impacto é preservado para auditoria com anonimização dos dados do usuário desativado
Se o colaborador for reatribuído no IdP, é reativado com todos os dados anteriores
Solução de problemas
Login SSO retorna erro
Verifique se os atributos enviados pelo IdP estão exatamente como email, firstName e lastName, sem variações de capitalização e sem namespace (no caso do Entra ID). Esses nomes precisam bater com os Required Attributes configurados na Daya.
Teste de conexão SCIM falha
Confirme que o token foi copiado por inteiro, sem espaços extras
No Okta, o prefixo Bearer (com espaço) precisa estar antes do token
No Microsoft Entra ID, o token vai sem prefixo, o sistema adiciona automaticamente
A Base URL precisa ser idêntica à da Daya, incluindo
/v2no final
Mudanças no IdP não refletem na Daya
A sincronização leva alguns segundos. Se passar de 1 minuto, verifique os logs SCIM no painel do IdP. Em caso de erro, entre em contato com [email protected].
