Férias, promoção e candidatura parecem formulários simples até a primeira pergunta difícil: quem pode aprovar, quem pode ver o salário e qual artigo da CLT barra o pedido. O RH Core é um projeto demonstrativo que responde a essas perguntas no código, e dá para testar cada resposta no navegador.
Um sistema de RH no Salesforce cabe em objetos customizados, Apex e LWC, mas o trabalho está nas regras: validar férias pela CLT antes do envio, decidir quem aprova cada etapa, garantir que só o RH leia salário e aceitar candidaturas de quem não tem login. O RH Core resolve essas quatro frentes num pacote só.
O projeto é demonstrativo, com a Vetra como empresa fictícia. O código está aberto no GitHub e a demo roda no navegador, com cinco personas: colaborador, gestor, RH, recrutador e candidato.
O que entra e o que fica de fora
São nove módulos sobre um núcleo comum: estrutura da empresa, férias, promoções, recrutamento, portal de vagas, onboarding, avaliação de desempenho, a tela Meu RH e o painel do RH. Todos usam o mesmo cadastro de colaborador e o mesmo motor de aprovação.
Folha de pagamento, ponto e eSocial ficaram fora de propósito. Esses sistemas têm regras fiscais próprias e costumam existir antes do CRM. O RH Core cuida do que costuma morar em planilha e e-mail: saldo de férias, pedido de promoção e candidato perdido entre a caixa de entrada e o quadro de vagas.
Férias pela CLT viram regra testável
O erro mais caro em férias é conceder fora da lei. O módulo de férias valida doze regras no momento do pedido, cada uma com mensagem em português e o artigo da CLT correspondente. Algumas delas:
| Regra | Base |
|---|---|
| Direito reduzido por faltas injustificadas (30, 24, 18 ou 12 dias) | art. 130 |
| Até três períodos, um com 14 dias ou mais e os demais com 5 ou mais | art. 134 |
| Início vedado nos dois dias que antecedem feriado ou descanso semanal | art. 134, § 3º |
| Abono de até um terço, pedido até 15 dias antes do fim do período | art. 143 |
A decisão de arquitetura foi isolar essas regras em LeaveRuleEngine, uma classe sem consulta e sem DML. Ela recebe o pedido, o período aquisitivo e os parâmetros, e devolve as violações. Por não depender do banco, cada regra tem teste unitário rápido e a mesma lógica foi portada para JavaScript na demo.
Os números da lei não estão no código. Prazos, frações e a tabela do art. 130 ficam em Custom Metadata, porque a convenção coletiva de cada categoria pode mudar esses valores, e mudar um parâmetro não deveria exigir deploy.
Para ver a regra do § 3º barrar um pedido, peça férias como colaborador começando numa sexta-feira.
Um motor de aprovação em vez do Approval Process
Férias passam pelo gestor direto e depois pelo RH. Promoções passam pelo gestor, pelo gestor do gestor e pelo RH. O Approval Process nativo atende fluxos assim, mas o aprovador do RH Core sai da hierarquia de colaboradores, que inclui pessoas sem usuário no Salesforce.
O ApprovalService lê as etapas de HR_Approval_Step__mdt, resolve o aprovador de cada uma pela cadeia de gestores e chama o handler do módulo quando o pedido é aprovado ou rejeitado. Duas regras de segurança ficaram no motor, e não na tela: só o aprovador da etapa decide, e uma etapa de gestor cujo aprovador seria o próprio solicitante é pulada com registro do motivo. Rejeitar exige comentário.
O custo é manter esse código. O ganho é testar o fluxo inteiro em Apex, inclusive o caso em que o gestor não tem usuário e a etapa precisa ser pulada. Para ver as duas etapas, aprove um pedido como gestor e observe o pedido seguir para o RH.
Quem vê o salário de quem
Acesso a dado de pessoa vem de três fontes. O colaborador vê o próprio registro. O gestor vê a equipe direta e indireta por Apex Managed Sharing, calculado a partir de Hierarchy_Path__c, um campo com o caminho da hierarquia. O RH vê tudo por permission set.
A hierarquia de papéis do Salesforce não serviu porque é por usuário, e parte dos colaboradores não tem login. O caminho em texto permite consultar a subárvore com LIKE. O limite é de 255 caracteres, cerca de treze níveis; acima disso o serviço recusa com mensagem clara.
Salário é outra camada. O campo só tem leitura no permission set do RH e as consultas usam WITH USER_MODE, então esconder o valor não depende da tela: o gestor não lê o campo nem pela API. Onde o código precisa de contexto de sistema, como criar compartilhamento ou gerar períodos aquisitivos, isso fica numa classe interna without sharing com o motivo comentado. O checklist de CRUD, FLS e sharing explica a diferença entre essas camadas.
Na demo, entre como gestor no organograma: a equipe aparece e o salário vem mascarado.
Portal de vagas para quem não tem login
O candidato usa um site Experience Cloud sem login, e o usuário convidado não tem acesso a nenhum objeto. O JobPortalController é o único ponto de entrada e devolve apenas DTOs com os campos permitidos, sem Id de registro, de gestor ou de recrutador.
Contra envio automatizado há três barreiras simples: um campo isca invisível, tempo mínimo entre abrir e enviar o formulário e limite diário por e-mail. Não é um antibot completo, e o projeto não finge que é.
O achado mais útil apareceu no site publicado. O runtime LWR entregava ao Apex um parâmetro de classe com todos os campos nulos, e os testes Apex não pegavam isso. A correção foi enviar a candidatura como texto JSON e converter no servidor. Para ver a ficha cair no funil, candidate-se pelo portal da demo.
Números e limites
O pacote tem 142 classes Apex, 12 triggers, 30 componentes LWC e 25 objetos. São 440 testes Apex com 97% de cobertura, 241 testes Jest e 62 testes das regras da demo. O Salesforce Code Analyzer não aponta violação de severidade 1 ou 2.
A versão do pacote ainda é beta, instalável em scratch org e sandbox. Trocar o gestor de alguém depois de lançar o ciclo de avaliação não recalcula o avaliador. A validação visual dos componentes dentro da org foi parcial. Esses pontos estão no README, junto do roteiro de instalação.
Perguntas frequentes
Dá para fazer um sistema de RH completo no Salesforce?
Dá para cobrir estrutura organizacional, férias, promoções, recrutamento, onboarding e avaliação com objetos customizados, Apex e LWC. Folha de pagamento, ponto e eSocial ficam fora e pedem sistemas especializados.
Por que não usar o Approval Process nativo para férias?
O Approval Process funciona bem para fluxos fixos. Um motor em Apex configurado por Custom Metadata permite etapas por tipo de pedido, aprovador resolvido pela hierarquia de colaboradores e testes unitários do fluxo inteiro.
Como esconder o salário do gestor no Salesforce?
Com permissão de campo. O campo de salário só tem leitura no permission set do RH, e as consultas rodam em user mode, então o valor não chega ao gestor nem pela API.
O RH Core usa dados reais?
Não. É um projeto demonstrativo com a Vetra, empresa fictícia, e dados inventados. As regras de férias seguem a CLT com parâmetros configuráveis e não substituem orientação jurídica.