Laboratório 4: licenças, permissões e configurações de receita
A fase 1 na prática, parte 1: as licenças e os conjuntos de permissões que a org Winter '27 do guia tem de verdade e a tela Configurações de receita, antes e depois dos pré-requisitos.
Décima quinta parte do guia e começo da fase 1. Licença contra conjunto de permissões, com a lista real da org, e a tela Configurações de receita antes e depois: o que cada pré-requisito pede, onde ele se liga e o que não pode ser desfeito. Com prints da org.
A fase 0 cuidou do dado. A fase 1 cuida da org: licenças, permissões e as configurações que precisam estar ligadas antes do primeiro produto. É a parte menos glamourosa do projeto e a que mais gera chamado de suporte quando é feita pela metade.
Este laboratório não começa do zero absoluto, e isso é de propósito. A org do guia é uma scratch org Winter '27 em português, já usada nos laboratórios das partes 9 a 11. Então, em vez de fingir uma org limpa, eu mostro o que ela tem e por que cada peça está ali. Se você quer a sua, a Salesforce oferece uma org de desenvolvimento com Revenue Cloud pelo cadastro do Trailhead. O setup é só em Lightning Experience.
Passo 1: licença abre a porta, permissão deixa entrar
Duas coisas parecidas e diferentes. A licença de conjunto de permissões (PSL) libera o acesso aos objetos e recursos de um produto para aquele usuário. O conjunto de permissões diz o que o usuário pode fazer lá dentro. Sem a licença, o conjunto de permissões nem pode ser atribuído. Sem o conjunto, a licença não serve para nada.
Consultei a org do guia para ver o que o usuário administrador tem atribuído. Estas são as licenças:
| Licença na org | Para que serve |
|---|---|
| Revenue Cloud User | Configuração de produto, cotação, pedido e ciclo de vida do ativo |
| Product Catalog Management Administrator | Catálogo, categorias, atributos e classificações |
| Salesforce Pricing Design Time e Run Time | Montar e executar procedimentos de precificação |
| Context Service Admin e Runtime | Definições de contexto e o uso delas em tempo de execução |
| Billing | Faturamento, que entra mais adiante no guia |
| Unified Catalog Admin | Administração do catálogo unificado |
E estes são os conjuntos de permissões, com os nomes que a org em português mostra:
| Conjunto de permissões | Nome de API |
|---|---|
| Designer de gerenciamento de catálogo de produtos | ProductCatalogManagementAdministrator |
| Administrador de precificação do Salesforce | CorePricingAdmin |
| Gerente de precificação do Salesforce | CorePricingManager |
| Usuário do horário de design e Usuário de hora de execução de precificação do Salesforce | CorePricingDesignTimeUser e CorePricingRunTimeUser |
| Administrador e Tempo de execução do serviço de contexto | ContextServiceAdminPsl e ContextServiceRuntimePsl |
| Transformar pedido em ativo | RevLifecycleManagementCoreCPQAssetization |
| Administrador de cobrança e Usuário de operações de cobrança | RevenueLifecycleManagementBillingAdmin e BillingOperations |
| APIs de preço, pedido, contrato, alteração e renovação | RevLifecycleManagementCalculatePricesApi, PlaceOrderApi e outras |
Três observações que economizam tempo:
- Os nomes mudam de tela para tela. A ajuda chama a licença de Salesforce Pricing Design Time User; a org mostra a licença sem o User e o conjunto de permissões com ele. Busque pelo nome de API quando a tradução atrapalhar.
- Vendedor não precisa de designer. Para o catálogo, a Salesforce define dois perfis de uso: Product Catalog Management Designer, para quem monta o catálogo, e Product Catalog Management Viewer, para quem vende.
- A licença Product Discovery User não existe mais. A licença e os conjuntos de permissões de Product Discovery foram descontinuados no Winter '25. Material antigo ainda manda atribuir; hoje o acesso vem dos conjuntos de catálogo.
Uma curiosidade útil: o administrador do sistema já tem acesso ao Context Service por padrão, sem licença extra.
A resposta sai do que está publicado aqui. Se não estiver, ele diz que não sabe em vez de inventar.