Melhores práticas no Process Builder
Olá, estou lendo um livro para aprender a codificação do apex e encontrei este parágrafo relacionado ao PB:
A melhor prática é garantir que, para um único objeto, haja um único processo Process Builder definido com todo o controle gerenciado por meio desse processo. Na prática, isso nem sempre é sustentável e pode exigir que o processo seja migrado para um acionador do Apex. Se você se encontrar em uma situação em que precisa de mais de um processo por objeto, deve considerar a migração desses processos para o Apex.
Battisson, Paul. Aprendendo o desenvolvimento do Salesforce com Apex: Escreva, execute e implante o Apex Code com facilidade (edição em inglês) (p. 26). Publicações BPB. Edição Kindle.
O que entendi disso é que todas as atualizações feitas em um objeto no Construtor de processos devem ser executadas em apenas 1 processo ?!
Estou meio preocupado, visto que temos cerca de 10+ Processos em cada um de nossos objetos ...
Respostas
Ter um único construtor de processos para um objeto é a abordagem certa, mas a exceção a essa regra é quando você tem um construtor de processos para eventos de criação e outro para eventos de atualização.
Para o limite de PB para um objeto Verifique esta pergunta em salesforce.stackexchange.com
Para as melhores práticas para o construtor de processos, acesse estes links:
10 melhores práticas para PB
Práticas recomendadas do Salesforce Process Builder
Se houver alguma outra dúvida que você pretendia fazer com esta pergunta, atualize a pergunta.
Felicidades
Sim, consolidar fluxos é considerada a melhor prática. Tendo trabalhado em uma organização onde fomos pressionados a consolidar nossos fluxos do Process Builder, posso falar sobre os pontos positivos e negativos. O motivo pelo qual fomos empurrados nessa direção é porque estávamos atingindo os limites do governador em nossas operações de salvamento para vários objetos. A consolidação desses fluxos corrige esse problema na medida em que seus fluxos contribuem para isso. Se você tem uma organização altamente complexa e observa as exceções de limite do governador, definitivamente deve considerar a consolidação de fluxo como uma etapa inicial para resolvê-los.
Quanto às desvantagens, existem algumas. Seu gerenciamento de versão se torna um pouco mais confuso, para começar. E o já pobre tratamento de erros de fluxos é exacerbado porque você basicamente só saberá "algo deu errado no Process Builder" sem nenhuma indicação de qual nó causou o problema. Embora as questões ao vivo enviem um e-mail de erro fornecendo mais detalhes, qualquer problema em um teste de unidade o deixa em paz. Você não terá literalmente nenhuma maneira de investigar a não ser executar o teste e esperar que possa rastrear o arquivo de log correto e sua seção. Isso pode ser bastante complicado se você tiver um erro que só acontece durante a validação da implantação, especialmente porque as organizações nas quais você deve considerar essa estratégia tendem a demorar muito para validar.
Se você consolidar, eu recomendo fortemente adicionar um campo ao seu objeto que permite que você ignore seus fluxos para fins de teste de unidade. Caso contrário, todo o seu sistema se tornará muito frágil para gerenciar.
Também li esta recomendação, mas para mim a manutenção / legibilidade dos processos é muito importante. Tenho exatamente 10 processos para Account, alguns deles para eventos de criação, alguns deles para eventos de atualização.
Alguns processos copiam campos, outros criam objetos, vários chamam um alerta de e-mail. Todos estes têm diferentes condições, é claro. Alguns até geram ações no futuro. Colocá-los em apenas dois processos (um para criação, um para atualização) resultaria em processos muito grandes, se é que isso pode ser feito.
Para falar mais sobre o aspecto da sustentabilidade: suponha que você tenha apenas um processo por objeto e suponha que você esteja trabalhando em uma nova funcionalidade, em uma sandbox. Digamos que uma solução rápida deve ser feita na produção. Essa correção não tem nada a ver com a nova funcionalidade, mas se aplica ao mesmo objeto. Então, você é obrigado a aplicá-lo em sua sandbox também, porque é um grande processo. E não é uma atualização elegante do processo: um changeset simplesmente adiciona uma nova versão, não mesclará nada.
Além disso, se você deseja desabilitar temporariamente uma parte da funcionalidade: quando você tem processos separados, basta desativar o apropriado. Se você tem um grande processo, bem, você tem que editar alguma condição, em algum lugar, eu acho, e lembrar onde você fez o quê. Boa sorte com isso.
Colocar todas as funcionalidades de um objeto em um grande processo vai contra todas as lições que aprendemos sobre sustentabilidade.
Portanto, por enquanto, estou mantendo-os em processos separados. Quanto à recomendação de migrar para classes Apex: isso é simplesmente ridículo. Você só deve considerar a programação do Apex se não puder cumprir os requisitos por meio de processos / fluxos / fluxos de trabalho. O código Apex é muito mais sujeito a erros e torna sua organização muito mais inflexível.