Forem: Liz Vidotti

Criando Salesforce Sanboxes

Liz Vidotti — Mon, 06 Oct 2025 13:38:11 +0000

No artigo anterior Configurar o DevOps Center, fizemos o passo a passo para a instalação e configuração do nosso aplicativo DevOps Center em nossa organização Salesforce. Agora, vamos criar algumas sandboxes que simulam o nosso pipeline do projeto.

Agora que o nosso DevOps Center foi configurado em nossa org e já temos as permissões necessárias para o nosso usuário, vamos criar algumas sandboxes para simular o processo de implementação em nossa org de produção.

Como já vimos no tópico O que são sanboxes?, em um projeto real, normalmente temos desenvolvedores trabalhando em suas tarefas nas sandboxes de desenvolvimento; estas tarefas são então mescladas no repositório e enviados para uma sandbox de testes; após as tudo ser devidamente testado, as alterações são encaminhadas para a sandbox de homologação, onde somos capazes de testar os pacotes de funcionalidades desenvolvidos por times diferentes, sem que elas comprometam o funcionamento do ambiente; após a homologação, levamos as alterações para uma sandbox de pré-produção (ou stagin), que é o ambiente mais próximo do ambiente de produção e nele podem ser feitos testes mais robustos, como testes de performance. Só ao final, temos a implantação no ambiente de produção.

Dessa forma, vamos criar algumas sandboxes e simular nosso pipeline, seguindo o fluxograma:

Para criação e gerenciamento de sandboxes, os usuários devem ter as seguintes permissões: nas configurações do perfil ou permission set, navegue até a seção System Permissions (permissões do sistema) e garanta que as opções estejam marcadas de acordo as necessidades de cada usuário.

Manage Dev Sandboxes: criar/editar apenas os metadados das sandboxes do tipo Developer e Developer Pro.
Manage Sandboxes: criar/editar sandboxes and sandboxes templates para todos os tipos de sandboxes.

No menu setup, procurar por Sandboxes. Na página, clicar no botão_ New Sandbox_. Você pode ver o número de licenças disponíveis para cada tipo, gerenciar as sandboxes existentes e visualizar o histórico de atividades.

Na página de criação, insira o nome da sua sandbox. Escolha um nome curto que reflita o propósito da criação do seu novo ambiente. Tenha em mente que o username dos usuários será o mesmo do de produção, mais o sufixo ".nomesandbox", então escolha nomes curtos que facilitem o preenchimento do username. No campo Create From, você pode escolher qual a origem da sua sandbox. Por padrão, a opção Production virá selecionada, mas se você tiver outras sandboxes criadas, elas também aparecerão nas opções. Por fim, selecione qual o tipo de sandbox você deseja criar. Em nosso caso, ela será a Developer. Então clique no botão Next correspondente a este tipo.

Selecione o tamanho do espaço de armazenamento da sua sandbox. Se você tiver upgrades disponíveis, poderá selecionar o maior valor (para nossa Developer, o upgrade é de 400MB e o padrão de 200MB). Eu deixarei o valor padrão de 200MB. Se você precisa que alguns scripts sejam executados após a criação ou atualização do seu ambiente, selecione a classe Apex que você criou previamente para essa função. Selecione também o grupo público de usuários que devem acessar este ambiente. É uma boa prática criar previamente os grupos públicos que devem acessar as sandboxes, e atribuir corretamente à medida que você cria uma nova sandbox.

Para as licenças Partial Copy e Full Sandbox, você tem a opção de dar acesso à todos os usuários ativos. Porém, isso impacta o tempo de criação da sandbox e a experiência de login dos usuários. Então, mantenha sempre as boas práticas de dar o mínimo acesso necessário para o cumprimento de suas tarefas.

Para a licença do tipo Partial, é obrigatória a seleção de um sandbox template na criação do ambiente. Já para a licença do tipo Full, você pode escolher entre um template ou copiar todos os dados. O Sandbox Template permite que você selecione objetos Salesforce e dados específicos que devem ser copiados, controlando o tamanho e conteúdo do seu ambiente.

Por fim, clique no botão Create. A criação do ambiente levará algumas horas, dependendo do tipo de sandbox. Você receberá um e-mail quando tudo estiver pronto, e também pode acompanhar o progresso na página Sandboxes.

Ao final, teremos os ambientes criados, de acordo com o nosso fluxograma.

Agora já temos tudo preparado! Vamos criar nosso projeto no DevOps Center e estabelecer a conexão com o Github, onde guardaremos o repositório do nosso projeto Salesforce. Bons estudos!

Referências

Create a Sanbox
Create or Edit Sandbox Templates

Configurar o DevOps Center

Liz Vidotti — Fri, 03 Oct 2025 11:47:29 +0000

No artigo anterior - Introdução ao Salesforce Devops Center -, aprendemos sobre os conceitos da prática devops e o DevOps Center, produto Salesforce destinado ao gerenciamento da esteira de desenvolvimento de um projeto Salesforce. Agora, vamos instalar o pacote do DevOps Center em nossa organização de estudos.

Aqui estarei utilizando uma organização Salesforce do tipo Partner Developer Edition. Ela simula uma organização de produção e me permite criar algumas sandboxes, ideal para nosso estudo de compreender como funciona um fluxo real de um projeto. Mas podemos utilizar a Salesforce Developer Edition, que é gratuita e também nos permite experimentar o DevOps Center.

No menu Setup, buscar por DevOps Center. Então, na página DevOps Center, marcar a opção Enable Devops Center. Logo abaixo, o botão Install Package estará disponível para instalação do pacote. Daí só seguir os passos de instalação. Eu estarei instalando o produto apenas para os Administradores do Sistema, então basta escolher a opção Install for Admins Only e clicar no botão Install.

A instalação deve levar algum tempo. Você deve receber a notificação no seu e-mail, mas você também pode acompanhar o progresso de instalação no menu Setup > Installed Packages.

Agora precisamos criar um Connected App. O connected app permite que aplicações externas possam integrar com o Salesforce, utilizando APIs e outros protocolos. Dessa forma, podemos, por exemplo, executar aplicações externas utilizando o Salesforce, ou podemos ler dados do Salesforce utilizando aplicações externas.

Ainda no menu Setup, vamos buscar pela seção External Client Apps, e clicar na opção Settings, logo abaixo dela. Se certifique que a opção Allow creation of connected apps está marcada e vamos clicar no botão New Connected App.

Crie o Connected App com as seguintes configurações e clique no botão Save.

Na página do connected app criado, clique no botão Manage. Então vá na seção Permission Sets, clique no botão Manage Permissions Sets e selecione a opção sf_devops_NamedCredentials.

Ainda no menu Setup, navegue até a página Session Settings e garanta que a opção Lock sessions to the IP address from which they originated esteja desmarcada.

Agora, vamos atribuir algumas permissões para o nosso usuário. A Salesforce disponiliza algumas permission sets para o DevOps Center:

DevOps Center: permissão base para utilização do DevOps Center. Ela permite gerenciar e criar Work Items, visualizar os ambientes conectados e o pipeline. Todos os usuários que devem acessar o DevOps Center precisam dessa permissão;
DevOps Center Manager: permite configurar e gerenciar os projetos, ambientes e usuários. Necessário para os líderes do projeto ou do time;
DevOps Center Release Manager: permite que o usuário possa realizar implementações através do pipeline. Ideal para os usuários responsáveis pelas implementações e outros usuários que precisam de permissão para gerenciar as mudanças ao longo do pipeline;
sf_devops_InitializeEnvironments: gerenciar as conexões entre os diversos ambientes. Ideal para os líderes do projeto ou do time;
sf_devops_NamedCredentials: acesso às credenciais necessárias para autenticação dos ambientes conectados. Ideal para todos os usuários que precisam acessar o DevOps Center.

Dessa forma, garanta que estas permissões estejam atribuídas ao seu usuário. Ao adicionar novos usuários, é importante levar em consideração os papéis de cada um ao atribuir as permission sets. Lembre sempre das boas práticas: os usuários devem ter o mínimo acesso necessário para executar suas tarefas.

Tudo configurado! Agora você pode atualizar o seu navegador, e procurar o aplicativo DevOps Center no App Launcher. Ao clicar no item, você será direcionado para outra guia, onde verá página inicial do DevOps Center.

Nosso próximo passo será configurar algumas sandboxes para simular o nosso pipeline no DevOps Center e criar uma conexão com nosso Github. Bons estudos!

Referências

Get Started with DevOps Center
Enable and install DevOps Center in the org
Assign the DevOps Center Permission Sets
Connected Apps

Introdução ao Salesforce Devops Center

Liz Vidotti — Thu, 02 Oct 2025 12:09:11 +0000

Este breve artigo é resultado dos estudos sobre o DevOps Center da Salesforce. Aqui exploro alguns conceitos iniciais da prática DevOps e como o DevOps Center traz essas práticas para projetos Salesforce.

O que é DevOps

DevOps é um conjunto de práticas, culturas e ferramentas que visam a integração e automatização dos processos entre o desenvolvimento de software e os times de TI.

Sua origem se deu por volta de 2007, quando os times de desenvolvimento e de operações começaram a levantar preocupações sobre o modelo vigente até então, onde o trabalho era feito de forma completamente apartada; os desenvolvedores participavam apenas no processo de desenvolvimento e o time de operações trabalhava apenas com o processo de deploy e pós-deploy. Então veio a proposição de unir os times em um processo integrado e contínuo durante o ciclo de vida do produto, trazendo velocidade e qualidade nas implantações de software.

Fonte: What Is DevOps?

Segue uma pequena descrição das fases do fluxograma acima:
1. Discover: Fase de exploração, organização e priorização das ideias. Elas devem estar alinhadas com as metas gerais e entrega de valor do projeto para os usuários finais.
2. Plan: Planejamento e gerenciamento do projeto, a partir dos resultados da fase de discover.
3. Build: Fase de desenvolvimento das soluções propostas nos estágios anteriores.
4. Test: Testes de software, que garantem a qualidade e integridade das entregas, garantindo que os fluxos estejam de acordo com os critérios de aceitação descritos na fase de planejamento.
5. Deploy: Processo de implementação das soluções propostas em ambiente produtivo.
6. Operate: Gerenciamento das entregas das funcionalidades para os usuários finais do software/sistema. Aqui também pode acontecer os treinamentos com os usuários do sistema.
7. Observe: Monitoramento para identificação dos problemas que possam afetar a qualidade do ambiente.
8. Continuous feedback: Coletar feedbacks dos usuários finais para garantir novas entregas de valor que possam agregar o software/sistema.

O que é o DevOps Center

Produto para gerenciamento de alterações e implantações, promovendo integração entre os diversos ambientes Salesforce. Ele permite o uso das boas práticas de DevOps através de uma interface centralizada e fácil de utilizar.

O DevOps Center permite Integração rápida com o Github (a integração com o Bitbucket ainda está em BETA até o momento em que esse artigo está sendo escrito). A integração com o repositório permite a centralização do projeto, onde podemos facilmente retornar versões anteriores e manter a versão final completa e segura, atualizando os ambientes de desenvolvimento com as mudanças feitas por cada membro do time.

O gerenciamento do projeto no Devops Center é feito principalmente com o a utilização dos work items. Work Item é um objeto Salesforce criado para o DevOps Center. Ele permite que novas funcionalidades ou alterações propostas sejam enviadas e rastreadas durante todo o ciclo de desenvolvimento. Assim, podemos saber saber quais foram as mudanças e em quais estágios do pipeline elas aconteceram.

Quando work items diferentes possuem informações conflitantes que precisam ser resolvidas, podemos facilmente identificar e mesclá-las corretamente num único fluxo, mantendo a integridade e consistência do projeto.

Com seu uso, é possível verificar a lista de metadados e selecionar aqueles que devem ser migrados para os demais ambientes. A visualização do pipeline de desenvolvimento é simples e você pode rapidamente implantar alterações de uma fase para outra, ou migrar as alterações entre ambientes.

As atividades de desenvolvimento podem ser feitas tanto na interface do DevOps Center, quanto localmente, com o uso do Salesforce CLI. Isso permite que tanto desenvolvedores quanto administradores do sistema possam trabalhar de forma colaborativa, pois sua interface é amigável para aqueles profissionais que não estão acostumados com o uso do Salesforce CLI e IDEs de desenvolvimento.

O que são Sandboxes?

Durante o processo de desenvolvimento, normalmente seguimos uma ordem: o desenvolvedor constrói e realiza seus testes unitários sobre os componentes criados. Então, as atividades de cada desenvolvedor do time são reunidas num ambiente integrado, onde são realizados os testes manuais ou automatizados que garantam a qualidade e estejam de acordo com os requisitos mapeados durante a fase de descobrimento e planejamento. Então, após a fase de testes, normalmente são feitas implantações em ambientes de homologação e pré-produção, onde temos testes mais robustos de integração e performance, pois estes ambientes são os mais próximos do ambiente produtivo. Por fim, chega a hora de implantação em produção.

Cada fase de desenvolvimento é feita em ambientes diferentes, ou sandboxes. Salesforce Sandboxes são cópias isoladas do ambiente de produção, que permitem que os times de desenvolvimento testem as mudanças de forma isolada e conduzam implementações sem comprometer os dados reais. Múltiplas sandboxes permitem a colaboração entre os times, controle de versões, minizando riscos no sistema.

A Salesforce disponibiliza alguns tipos de sandbox:

Developer Sandbox Pode ser atualizada diariamente, possui 200MB para armazenamento de dados e 200MB para armazenamento de arquivos. Todos os metadados de produção são copiados para esse ambiente. Mais comumente utilizada para desenvolvimento e testes unitários.
Developer Pro Sandbox As mesmas configurações da sandbox Developer, com exceção do limite de armazenamento: 1GB para dados e 1BG para arquivos.
Partial Copy Sandbox Pode ser atualizada a cada 5 dias, possui 5GB para armazenamento de dados, e o armazenamento de arquivos é o mesmo da organização de produção. Todos os metadados e alguns dados são copiados da organização de produção. Mais comumente utilizada para testes, como: testes de aceite e testes de integração, e treinamento com os usuários finais.
Full Sandbox Pode ser atualizada a cada 29 dias, possui os mesmos espaços de armazenamento de dados e arquivos da organização de produção. Todos os metadados e dados são copiados da organização de produção. Mais comumente utilizada para testes de performance e carregamento.

Referências

What Is DevOps?
DevOps Tutorial
DevOps Center: Quick Look
Salesforce Sandboxes
Sandbox Types and Templates

Gerador de documentos para o Salesforce Industries

Liz Vidotti — Mon, 29 Jan 2024 18:53:37 +0000

O Gerador de Documentos para Industries é uma aplicação que permite que o usuário crie documentos a partir de templates pré-definidos ou templates customizados. Dessa forma, os documentos são gerados de forma rápida, consistente e precisa.

Com esta aplicação, podemos mesclar arquivos de texto, como editor de textos ou de slides com outras fontes de dados, como registros de objetos Salesforce, para criar contratos, propostas, cotações e relatórios. Os documentos gerados podem ser exportados no formato .docx, .ppt e .pdf.

Vantagens

Gerar documentos de forma rápida e precisa;
Controle de versões, onde podemos criar diversas versões de um único template, de acordo com as mudanças que atendam as necessidades de negócio;
Contratos de venda com a capacidade de mesclar dados de mais de um objeto Salesforce;
Documentos de proposta detalhados, que mesclam diversos segmentos de dados em um único documento;
Cotações complexas e integradas;
Criação de relatórios simples e/ou complexos.

Document Template Designer

Esta ferramenta permite criar templates de documentos a partir de templates existentes ou completamente novos, de forma declarativa, ou seja, sem a necessidade de códigos. Podemos configurar parágrafos, colunas, mesclar textos e imagens, etc. Os templates ajudam a otimizar os processos de negócio.

Ela permite que os documentos sejam gerados em formato HTML, Microsoft Word (.docx) e Microsoft PowerPoint (.pptx). Para a criação de documentos complexos, que necessitam de cálculos, lógica e inserção de dados dinâmicos, podemos configurar tokens para os templates, que suportam diversos tipos e funções:

Variáveis: podemos passar as informações necessárias, em formato JSON, para o preenchimento do documento. Essas informações são armazenadas em variáveis e permitem que os dados sejam preenchidos de forma dinâmica;
Conteúdo de repetição: podemos inserir, por exemplo, listas de produtos em um único documento;
Condicionais: podemos inserir determinada informação quando condições pré-definidas no template são atendidas;
Imagens;
Editor de textos: podemos configurar cor, fonte, parágrafos, etc;
Hyperlink: podemos inserir URLs dinâmicas para a criação de documentos.

Mapeamento de dados

Podemos mesclar dados de registros de objetos Salesforce para a criação de documentos. Os objetos que podem ser utilizados são: Contract, Opportunity, Order e Quote. Podemos criar diversas seções no mesmo documento, onde cada seção importa dados de um único objeto.

O mapeamento de dados baseado em objetos é tipicamente usado para criar documentos no formato HTML. Ele é de fácil construção, porém é menos flexível do que o mapeamento de dados JSON.

Também é possível mesclar dados de sistemas externos ao Salesforce. Esses dados devem ser integrados ao Salesforce no formato JSON. Podemos criar um componente DataRaptor ou classe Apex para extração e formatação dos dados que serão enviados para o gerador de documentos.

O mapeamento de dados baseado em dados JSON é usado para a criação de documentos HTML, Microsoft Word e Microsoft PowerPoint, e a fonte de dados pode ser interna ou externa ao Salesforce.

Para que possamos inserir as informações necessárias para a geração de documentos, utilizamos os chamados tokens. Esses tokens podem ser de vários tipos:

Variável: mostra o valor da variável que é passada para o template através de elemento no formato JSON;

{{token_name}}

Conteúdo de repetição: repete o conteúdo de uma seção;

{{#token_name}} //o sinal # indica que o conteúdo se repete tantas vezes forem a quantidade de itens dos dados de entrada no formato JSON
{{/token_name}} //aqui é indicada a _tag_ de fechamento
AND
{{^token_name}} //o sinal ^ indica o que deve ser exibido caso o item não exista ou esteja vazio.
{{/token_name}} //aqui é indicada a _tag_ de fechamento

Condicionais: se determinada condição é verdadeira, a seção é mostrada no documento;

{{#IF_token_name}} //aqui, a seção aparecerá somente se a condição for VERDADEIRA
{{/IF_token_name}} //tag de fechamento
AND
{{^IF_token_name}} //aqui, a seção aparecerá somente se a condição for FALSA
{{/IF_token_name}} //tag de fechamento

Imagem: inserir imagem de forma dinâmica;

{{IMG_<imagetokenname>}}

Rich text: mostra o conteúdo rich text em seu formato original;

{{RTB_<richtexttokenname>}}

Hyperlinks: inserir URL dinâmica;

{{HYP_<hyperlinktokenname>}}

Os dados recebidos podem vir de uma classe Apex ou do componente DataRaptor.

Client-side & server-side

Podemos criar processos para geração de documentos através de componentes Omniscript, Integration Procedure e classes Apex. O processo pode ser client-side ou server-side.

Client-side: o processo é tipo síncrono, através de um componente Omniscript, onde o usuário precisa executar ações, como preenchimento de informações necessárias para a geração do documento. Este processo utiliza recursos do navegador web e, por estes motivos, funciona com arquivos menores.
Server-side: o processo é tipo assíncrono, ou seja, ocorre através de um processo automático, sem a necessidade de interação do usuário. Este processo utiliza recursos do próprio Salesforce, o que permite a criação de arquivos maiores e criação de arquivos em lote.

Client-side

Para preencher as informações necessárias na criação de documentos client-side, podemos:

Criar um Omniscript: podemos criar um Omniscript que capture os dados de entrada do usuário em um formulário e leve os dados para o document template;
Customizar o Omniscript padrão na plataforma: para que o Omniscript seja capaz de gerar o documento, o template configurado deve ter sempre dois DataRaptors relacionados; o DataRaptor Extract e o DataRaptor Transform;
Uitilizar a entrada de dados do tipo JSON: podemos criar um classe Apex que extraia os dados do Salesforce e leve os dados no formato JSON para o document template. Este processo é ideal para documentos que possuam mais de 200 itens.

Server-side

Automatizar a geração de documentos com APIs;
Utilizar diversas ferramentas, como classes Apex, Integration Procedures e Omniscripts;
Gerar documentos mais pesados e/ou múltiplos documentos através de processos batch, que utilizam os recursos do Salesforce, ao invés dos recursos do navegador. Documentos mais pesados normalmente possuem muitas linhas, tabulação complexa e muitos tokens;

Fonte:
Deep Dive into Salesforce Document Generation
Industries Document Generation Foundation

Introdução ao Business Rules Engine

Liz Vidotti — Thu, 18 Jan 2024 17:50:11 +0000

Este conjunto de componentes, objetos e serviços é utilizado para desenhar regras de negócio que irão compor processos de negócio automatizados em um fluxo de trabalho. O Business Rule Engine (BRE) é capaz de fazer cálculos e pesquisas complexas.

O BRE está disponível para o Flow e o Omnistudio nas nuvens de Industries. Também é possível integrar APIs com fluxos de trabalhos criados a partir de ferramentas de terceiros ou customizadas, como códigos Apex. O fluxo de trabalho criado passa os dados necessários para acionar o BRE e este retorna os dados para o fluxo.

Os componentes chave do BRE são:

Expressions sets;
Lookup tables;
- Decision matrices;
- Decision tables.

Como o BRE interage com as ferramentas de fluxo de trabalho?

Flow Os componentes do BRE (decision matrices, decision tables e expression sets) estão disponíveis através de componentes de ação no Flow. As decision tables podem ser acionadas a partir de um expression set ou diretamente através do Flow.
OmniStudio Os Expression Sets e Decision matrices estão disponíveis através de elementos de ação nas Integration Procedures e Omniscripts.
Ferramentas customizadas ou de terceiros Podemos utilizar as Connect APIs para acionar as Expression sets e as Lookup tables através dos fluxos de trabalhos criados com estas ferramentas.

Expression Set

Consiste num fluxo lógico, dividido em diversos passos, construído com variáveis, constantes, condições, cálculos, pesquisas, etc.

Os dados de entrada e de saída são em formato JSON. Assim como a ferramenta Flow, podemos criar diversas versões do mesmo Expression Set. Ao criar uma nova versão, devemos informar a data e hora de início e o Rank. Duas versões diferentes podem estar ativas, e o fluxo que será acionado será com o de maior data e hora de início e maior Rank.

Variáveis e constantes: são usadas para armazenar valores dinâmicos no fluxo. Ele pode ser usado para armazenar informações dos valores de entrada e saída, além de valores que precisam passar de uma etapa a outra no mesmo fluxo;
Variáveis de objeto: para trabalhar com valores dos campos de um objeto Salesforce, devemos configurar aliases para os objetos e os campos. Eles estão disponíveis para criação no menu de configuração e podem ser categorizados;
Tipos de dados: os tipos de dados que podem ser utilizados em um expression set podem ser
- Text;
- Number;
- Percent;
- Currency;
- Date;
- Date & Time;
- Boolean;
Operadores e funções: podemos utilizar operadores lógicos, de comparação, matemáticos e de string, além de funções de data e numéricas.

Decision Explainer

Podemos utilizar este serviço para mostrar ao usuário explicações de cada etapa do Expression Set, e para armazenar logs de ação.

As mensagens explicativas devem ser configuradas como templates, no menu de configurações (Explainability templates). Por sua vez, os templates devem ser adicionadas em cada etapa desejada do seu Expression Set.

Quando você utiliza o simulador do Expression Set para os testes, você poderá ver as mensagens na opção Concise View.

Decision Matrix

Com base no(s) valor(es) de entrada, recebemos o valor de saída correspondente da linha da tabela. Ela é útil para implementar regras complexas de uma maneira sistemática e de fácil leitura. Os dados de entrada e saída são no formato JSON.

Decision Table

Com base no(s) valor(es) de entrada, recebemos o(s) valor(es) de saída. Os valores de saída podem ser com base com os valores especificados na tabela, ou com base nos registros do Salesforce.

Na criação de uma decision table, devemos escolher o objeto de origem, e até quatro objetos relacionados ao objeto de origem. Os objetos relacionados devem estar até três níveis adjacentes do objeto de origem.

Fonte: Documentação oficial: Business Rule Engine

DataRaptor Load

Liz Vidotti — Mon, 18 Sep 2023 13:22:29 +0000

DataRaptor é um componente do Salesforce Omnistudio, que faz parte da camada Service Management. Ele é essencialmente um componente de backend, que permite leitura, escrita e transformação de dados no Salesforce. Ele é dividido em quatro tipos: Extract, Turbo Extract, Load e Transform. Nesse artigo, irei explicar um pouco sobre o DataRaptor Load, utilizando um exemplo prático.

O DataRaptor Load permite a criação e edição de dados no Salesforce. Os dados de entrada podem ser dos tipos: JSON, XML _ou formato customizado. Estes dados podem ser obtidos através de: outros componentes do _Omnistudio, como Omniscripts e Integration Procedures; DataRaptor API Rest call; classes Apex.

Apenas o Omnistudio for Vlocity têm suporte para receber dados através de objetos de Interface, como o Salesforce Bulk Loader e outras ferramentas similares.

Os dados de saída contém os registros e Ids dos registros criados e/ou atualizados. Esses registros serão sempre de sObjects, ou objetos do Salesforce, que podem ser os objetos padrão, como Contas e Oportunidades, ou objetos customizados.

Durante o processamento do DataRaptor Load, temos as seguintes etapas:

Etapa de Fórmula: funções matemática e de Strings são processadas para atender a resultados de fórmulas específicas, quando criadas;
Etapa de Transformação: é quando os dados de entrada são mapeados para os dados de saída correspondentes;
Etapa de Carregamento: quando os dados são persistidos em um sObject.

Hands-on

Criar um componente DataRaptor Load que receba uma lista de gêneros de filmes, e grave os dados em um objeto customizado Genre__c.

Para este projeto, estarei usando os dados da API do DB Movies. Estou usando também a org Developer Edition com o pacote do Omnistudio já instalado.

Antes de iniciar a construção do componente, criei o objeto Genre (Genre_c), e dois campos do tipo Texto, Id (Id_c) e Name. O perfil de usuário Administrador do Sistema terá acesso de criação, leitura e edição para o objeto e seus campos.

No aplicativo Omnistudio, vamos acessar a guia DataRaptor e criar um novo componente, com a interface Load.

Na guia Objects, selecionar o objeto Genre__c.

Na guia Fields, vamos copiar a lista de gêneros e colar na seção Input JSON. Logo após, vamos clicar em Quick Match.

{
  "genres": [
    {
      "id": 28,
      "name": "Action"
    },
    {
      "id": 12,
      "name": "Adventure"
    },
    {
      "id": 16,
      "name": "Animation"
    },
    {
      "id": 35,
      "name": "Comedy"
    },
    {
      "id": 80,
      "name": "Crime"
    },
    {
      "id": 99,
      "name": "Documentary"
    },
    {
      "id": 18,
      "name": "Drama"
    },
    {
      "id": 10751,
      "name": "Family"
    },
    {
      "id": 14,
      "name": "Fantasy"
    },
    {
      "id": 36,
      "name": "History"
    },
    {
      "id": 27,
      "name": "Horror"
    },
    {
      "id": 10402,
      "name": "Music"
    },
    {
      "id": 9648,
      "name": "Mystery"
    },
    {
      "id": 10749,
      "name": "Romance"
    },
    {
      "id": 878,
      "name": "Science Fiction"
    },
    {
      "id": 10770,
      "name": "TV Movie"
    },
    {
      "id": 53,
      "name": "Thriller"
    },
    {
      "id": 10752,
      "name": "War"
    },
    {
      "id": 37,
      "name": "Western"
    }
  ]
}

No popup que se abre, vemos na esquerda, a lista de paths do JSON de entrada; no meio, os campos do referido objeto (Genre__c); e, na direita, ficarão os campos mapeados. Podemos clicar em Auto Match, ou arrastar o path da esquerda para o campo correspondente. Se os campos estiverem mapeados corretamente, clicar em Save.

Vamos editar o mapeamento para o path genre:id, e marcá-lo como Upsert Key; desta forma, se o Salesforce encontrar um gênero com o mesmo genre:id, ele irá atualizar o registro, ao invés de criar um novo.

Na aba preview, vamos testar o componente. Colamos o JSON de entrada na seção input, e clicamos em Execute.

Quando a operação é executada com sucesso, vemos a lista de registros criados, junto com os Ids do Salesforce.

OmniStudio DataRaptors

Liz Vidotti — Wed, 08 Mar 2023 17:15:39 +0000

Nesse artigo, vamos aprender sobre um dos componentes da camada Service Management do OmniStudio. O DataRaptor é uma ferramenta de mapeamento de dados que nos permite ler, transformar e escrever dados no Salesforce. Este componente pode enviar e receber dados de outros componentes do OmniStudio, como FlexCards, OmniScripts e Integration Procedures, além de aplicativos e APIs externas. Também pode acessar objetos externos, metadados customizados e objetos Salesforce.

Podemos pensar: mas podemos fazer a mesma coisa utilizando classes Apex. Porque eu deveria utilizar um DataRaptor?

Utilizar o DataRaptor torna o desenvolvimento mais rápido, além de facilitar as futuras manutenções em sua Organização.

Por ser uma ferramenta de desenvolvimento declarativo, sem a necessidade de código, o desenvolvimento e manutenção se tornam mais rápidos do que o desenvolvimento de uma classe Apex.

Tipos de DataRaptor

DataRaptor Turbo Extract
- Capaz de fazer a leitura de apenas um objeto Salesforce;
- Capaz de fazer a leitura de campos de objeto relacionado;
- Podemos filtrar quais registros queremos exibir baseados em critérios de campos;
- Não suporta a utilização de fórmulas ou dados de saída complexos;
- Os dados de entrada (input) são sempre um sObject (objeto Salesforce) e os dados de saída (output) podem ter o formato JSON ou customizado;
DataRaptor Extract
- Capaz de fazer a leitura de um ou mais objetos Salesforce, não importa se são objetos relacionados;
- Capaz de extrair dados de até três objetos relacionados;
- Os dados de entrada (input) e os dados de saída (output) podem ser em formato JSON, XML ou customizado;
- Capaz de organizar os dados através de paginação, utilizando o offset. Com esse recurso, podemos recuperar os dados da requisição a cada vez, baseados em valores de campos ou outros critérios;
DataRaptor Load
- Capaz de criar e/ou atualizar registros para um ou mais objetos Salesforce;
- Os dados de entrada (input) podem estar no formato JSON, XML ou customizado, e os dados de saída (output) são sempre um sObject;
DataRaptor Transform
- Capaz de manipular dados internos ou externos ao Salesforce;
- Capaz de dividir, reestruturar e transformar dados nos formatos JSON, XML ou schemas customizados;
- Capaz de renomear nomes de campos;
- Podemos usar fórmulas e funções para a transformação dos dados;
- Podemos preencher modelos de documentos para o Docusign ou PDF.

OmniStudio Omniscripts

Liz Vidotti — Wed, 01 Mar 2023 11:33:35 +0000

O Omniscritpt é o segundo componente que encontramos na camada Digital Experience do OmniStudio. Podemos defini-lo como um caminho guiado para completar um processo do negócio. Ele funciona como um conjunto de Flexcards usados para atender um processo, como criar uma nova cotação de um seguro de automóvel.

Este componente tem o foco na experiência e na interface do usuário, permitindo maior engajamento e tornando a experiência do usuário dinâmica e personalizada.

Características

Desenvolvimento de forma declarativa ou drag-and-drop. Podemos visualizar a prévia do componente e utilizar o debbuger para testar o funcionamento do componente antes de ativá-lo;
Podemos implementar o componente em qualquer canal ou dispositivo;
Possui arquitetura modular, que permite a separação das camadas de backend e frontend;
As informações disponíveis de um Omniscript podem vir de diversas origens de dados: do próprio Salesforce, de um website ou sistema legado;
Grande capacidade de customização do componente. Temos a opção de customização em dois frameworks: o Lightning StyleShhet e o Newport Design System;
Podemos gerenciar a assinatura de documentos com o OmniScript
- Templates para a criação de documentos;
- Mesclar informações de diversas fontes de dados;
- Anexar documentos aos registros de objetos Salesforce ou enviá-los por email;
- Utilizar o DocuSign para assinatura eletrônica.

OmniScripts vs. Screen Flows

Podemos pensar que o OmniScript é um tipo de Screen Flow para as nuvens de Industries.

Ambas ferramentas são usadas para a criação de processos guiados, que fazem a leitura e permitem a inserção de informações. Também possuem outras similaridades:

O fluxo pode seguir diferentes ramificações, dependendo de condicionais estabelecidas;
Componentes modulares;
Leitura e/ou edição de dados do Salesforce;
O fluxo pode disparar a execução de uma classe Apex ou componente do Lightning Web Component (LWC);
Podem ser incorporados em páginas web externas;
São componentes responsivos;
Possui ferramenta para execução de testes sobre o funcionamento do fluxo (debugger).

Porém, com o OmniScript, podemos:

Trabalhar com hierarquia complexa de dados;
Estilizar o componente com CSS;
Criar interações com dados internos e externos;
Criar validações mais complexas;
Criar formulários dinâmicos;
Interface de usuário flexível para apresentar informações e capturar dados;
Adicionar múltiplos registros.

Referências

-[OminiScripts[(https://trailhead.salesforce.com/pt-BR/content/learn/modules/omnistudio-omniscript?trail_id=get-to-know-omnistudio)

OmniScripts with branching

OmniStudio Flexcards

Liz Vidotti — Wed, 22 Feb 2023 11:37:53 +0000

No último post, falei sobre o que é o Omnistudio e quais as camadas que o compõe. Saiba mais em Introdução ao OmniStudio

Nesse artigo, vamos aprender sobre o componente Flexcard. Ele faz parte da camada chamada Digital Experience. Podemos conceituar o Flexcard como um componente que mostra informações e ações rápidas de forma simples e objetiva.

O Flexcard otimiza o tempo de desenvolvimento de soluções customizadas, que normalmente utilizam as tecnologias HTML, CSS e Javascript, através do desenvolvimento declarativo, ou configurações baseadas em cliques. Com ela, podemos adicionar e estilizar campos, botões, links, rótulos de campo (labels), ícones, imagens e gráficos facilmente através do designer canvas.

Características

Ele combina informações e ações estratégicas ao negócio. Com poucos cliques, podemos obter informações e imputar dados de maneira eficiente e rápida;
Ao editar/atualizar as informações, o flexcard reflete as mudanças em tempo real;
Podem ser implementados em qualquer canal ou dispositivo, como: Lightning Page, Community, Sistema de Gerenciamento de conteúdo externo ou Container web customizado;
As informações mostradas num flexcard podem ter diversas origens de dados, como: o próprio Salesforce, website ou sistema legado;
Ele é construído de forma declarativa ou drag-and-drop. Para modificar o estilo do componente, podemos usar o editor ou CSS customizado. As modificações são exibidas automaticamente no canvas, que é o espaço que nos apresenta a prévia do componente;
Podemos incluir botões de ações em um FlexCard, como
- Carregar um fluxo com processo guiado
- Exibir um flyout com informações adicionais
- Navegar para outro registro
- Ouvir um evento de outro flexcard e atualizar o flexcard em questão quando o evento é disparado;
- Notificar um componente em outra página ou aplicação de que um evento ocorreu;
Podemos incorporar um ou mais componentes dentro de um flexcard principal;
Podemos incorporar o flexcard em um Omniscript, ou processo de interação guiada;
Podemos incluir o flexcard em um flyout, que nos permite exibir informações adicionais ou secundárias em componentes separados;
Podemos definir estados e condicionais para o flexcard, onde o conteúdo e ações disponíveis ao usuário podem mudar de acordo com o tipo ou status da informação.

Child Flexcard

Como vimos anteriormente, podemos incorporar um ou mais flexcards em um único flexcard.

Ao criar um novo componente, temos um campo chamado "Is Child Flexcard". Quando este campo está marcado, significa que este componente pode ser utilizado em mais de um flexcard. Não há limite para a quantidade de child flexcards presentes num parent flexcard. Para adicionar um novo child flexcard no flexcard principal, ele precisa estar ativo.

Também podemos configurá-lo para que ele consuma fontes de dados oriundas de seu parent ou componente principal, ou funcione de maneira independente, consumindo fontes de dados distintas. Isso nos permite utilizar diversas fontes de dados em um único componente. É importante lembrar que, ao configurar o flexcard principal para enviar dados para os componentes relacionados, todas as origens de dados dos componentes relacionados são sobrescritas pela origem de dados do componente principal.

O flexcard pode consumir dados internos (do próprio Salesforce) ou externos. Os dados externos incluem qualquer dado de fora da sua instância Salesforce, ou Organização. É comum que as implementações requeiram o consumo de dados externos, como:

Origens de dados de sistemas legados;
Origens de dados on-premises (on-prem). Ele se refere a data centers privados mantidos pela própria empresa;
Integrações de API.

Flyout

O flyout ajuda na organização das informações que você deseja exibir em tela. Ele pode ser usado na forma de um popover ou modal. Ele é normalmente usado quando há a necessidade de exibir informações longas, que não cabem em um único flexcard.

Podemos incorporar o child flexcard em um flyout. Além de permitir a exibição de dados, também podemos incluir ações adicionais.

Tipos de flyout

Child Flexcard;
Omniscript;
Lightning Web Component (LWC);

Navigate action

Podemos incluir um botão de ação em nosso componente que direciona o usuário a uma outra página, que pode ser uma página do Lightning Experience ou Lightning Commmunity da própria organização, ou página web externa.

Flexcard States

Podemos definir estados e condicionais para o flexcard, onde o conteúdo e ações disponíveis ao usuário podem mudar de acordo com o tipo ou status da informação. Todo flexcard criado possui um estado, o estado padrão, ou default.

Para criar um novo estado, basta adicionarmos um novo elemento State ao canvas ou clonarmos um estado existente. Não há limite para o número de estados que podemos adicionar a um flexcard. A ordem dos estados é crucial para determinar qual tipo de informação será exibida. O processo começa no topo da lista e é percorrido até o último estado. Aquele que retornar as condições verdadeiras será exibido para o usuário final.

Melhores práticas: devemos ter apenas um estado verdadeiro por registro, e o último estado da lista será o estado default, ou padrão. Ele não tem condicionais, e é exibido se todos os outros estado anteriores a ele retornarem falso.

Publicando seu FlexCard

Ao ativar um FlexCard, geramos um novo componente LWC (Lightning Web Component) que pode ser publicado em uma Lightning Page ou Community Page.

Ao navegarmos no nosso editor do Lightning App Builder ou Experience Cloud, os componentes ficam disponíveis na seção Customizados (Custom).

Opções de publicação

Master label: esse é o nome que aparecerá na sua lista de componentes customizados no seu editor de páginas do Lightning ou editor da sua comunidade Salesforce;
API Version: aqui fica a versão da API em que foi desenvolvido o componente;
Runtime Namespace: define o nome do pacote Vlocity;
Is Exposed: define se o seu componente é público;
Add SVG Resource/Drop it here: define o ícone customizado do seu componente. Esse ícone aparecerá na lista de componentes customizados do seu editor de páginas do Lightning ou editor da sua comunidade Salesforce;
Targets: define em quais lugares o seu componente está disponível para publicação. Por padrão, não definimos targets para os child flexcards. Podemos definir como locais:
- App Page: página inicial do aplicativo
- Home Page: página inicial customizada
- Record Page: página de detalhes de registro de um objeto
- Community Page: site do Experience Builder
- Community Default: site do Experience Builder com propriedades configuráveis.

Versionamento vs. Clone

O versionamento nos permite fazer alterações em nosso componente sem alterar a versão original. Um flexcard pode ter múltiplas versões, mas apenas uma versão pode estar ativada por vez. Utilizamos o versionamento quando queremos realizar atualizações no componente, por exemplo, e temos necessidade de subsbtituí-lo.

Quando clonamos um flexcard, criamos um cópia independente do componente original, que pode ter um novo nome e autor, ao contrário do versionamento. Podemos ter vários clones ativados em uma organização Salesforce, mas apenas uma versão ativa de um único componente.

Referências

Documentação

OmniStudio Flexcards

OmniStudio FlexCard Building and Publishing

Introdução ao Salesforce OmniStudio

Liz Vidotti — Wed, 15 Feb 2023 12:54:47 +0000

O OmniStudio se apresenta como um pacote de engajamento digital centrado no cliente, onde as interações se dão de maneira eficiente, precisa e personalizada. Ele é capaz de criar processos automáticos que fazem a integração de dados entre sistemas e podem ser implementados em diferentes canais e dispositivos, como uma página web, Salesforce Community ou Lightning Page.

Com ele, podemos construir soluções altamente customizáveis de forma declarativa ou drag-and-drop. Esse tipo de desenvolvimento permite que os componentes sejam desenvolvidos em um tempo menor, e permitam atualizações mais rápidas, que podem ser feitas por administradores da plataforma ou desenvolvedores.

Sua arquitetura é orientada a microsserviços e modular, o que permite maior escalabilidade em picos de maior fluxo de dados. O OmniStudio utiliza a estrutura de dados JSON e interface RESTful, o que permite que os desenvolvedores possam utilizar outros serviços independentes, sem a necessidade de interação com outros desenvolvedores.

É importante lembrar que o OmniStudio só pode ser usado em organizações do Salesforce _com licença para nuvens de segmentos específicos, ou _Salesforce Industries:

Financial Service;
Health Cloud;
Manufacturing;
Communications;
Media;
Energy & Utilities;
Public Sector;
Insurance.

Podemos dividir o OmniStudio em três camadas:

Digital Experience;

É a camada de frontend, responsável por promover experiências de interação eficientes, através de interfaces de usuário com alta performance. Ela é formada por dois tipos de interfaces de usuário, que são os FlexCards _e _Omniscripts. Estes componentes são construídos com o Lightning Web Components (LWC), e configurados de maneira declarativa.

Service Management;

É a cama de backend, que inclui os serviços de dados responsáveis pela leitura, escrita, cálculo e rastreio dos dados dentro e fora do Salesforce. Ela é formada por: OmniStudio DataRaptors e Omnistudio Integration Procedures.

Developer Experience.

São ferramentas do ciclo de vida do aplicativo para que os desenvolvedores gerenciem e movam as alterações de componentes do OmniStudio _entre ambientes (desenvolvimento, testes e produção). Ela é formada por: _IDX Build Tool e IDX WorkBench.

Esse artigo é resultado dos meus estudos sobre o OmniStudio. A ideia é que eu faça uma série de artigos, com o intuito de documentar os estudos enquanto avanço nos temas. Breve estarei publicando artigos que descrevam melhor cada camada do OmniStudio.

Referências

Documentação
Get to Know OmniStudio