Você está aqui:
Comportamento especial em implantações
Use as informações aqui para determinar o que incluir em sua implementação e como as alterações aparecem no destino.
Os comportamentos listados na seção da API de metadados se aplicarão se você estiver usando Extensões do Salesforce para Visual Studio Code.
- Componentes do conjunto de alterações
Considere como processos de aprovação, Apex code, campos e objetos personalizados, fluxos e outros componentes personalizados afetam sua implantação. - API de metadados
Os comportamentos listados aqui se aplicam se você estiver usando Extensões do Salesforce para Visual Studio Code.
Consulte também:
Componentes do conjunto de alterações
Considere como processos de aprovação, Apex code, campos e objetos personalizados, fluxos e outros componentes personalizados afetam sua implantação.
Processos de aprovação
- Se os campos da página de aprovação incluírem quaisquer campos personalizados de objetos padrão, adicione manualmente esses campos personalizados aos conjuntos de alterações de saída. A opção Visualizar/Adicionar dependências para selecionar os componentes do conjunto de alterações não incluirá esses campos.
- Se o processo de aprovação fizer referência a quaisquer modelos de publicação que contenham campos personalizados, salve novamente esses modelos na organização de origem antes de adicioná-los ao conjunto de alterações. Em Configuração, na caixa Busca rápida, insira Configuração da Amazon e selecione Configuração da Amazon. Para cada modelo de publicação, clique em Editar e em Salvar.
- Os conjuntos de alterações não incluem a ordem dos processos de aprovação ativos da origem. Às vezes, é necessário reordenar os processos de aprovação na organização de destino após a implementação.
- Se você alterar o Nome exclusivo de um processo de aprovação anteriormente incluído em um conjunto de alterações e implementado em outra organização e reenviar o processo de aprovação por meio de um conjunto de alterações, um novo processo de aprovação será criado na implementação da outra organização. O processo de aprovação implantado anteriormente não será modificado.
Classes do Apex e acionadores do Apex
Por padrão, as alterações feitas no Apex code que possui tarefas do Apex pendentes ou em andamento não podem ser implantadas. Para implementar essas alterações, siga uma destas etapas.
- Cancele as tarefas do Apex antes de implantar as alterações no Apex code. Reagende os trabalhos após a implementação.
- Ative as implantações com as tarefas do Apex na interface de usuário do Salesforce na página Configurações de implantação.
Se um registro for criado em um teste do Apex, o registro de teste não será marcado como visualizado. Portanto, os testes do Apex com consultas que filtram por LastViewedDate falham durante a implantação e podem causar falhas na cobertura de código. Para marcar um registro como visualizado em um teste do Apex, use primeiro a cláusula FOR VIEW e, em seguida, filtre por LastViewedDate.
Este exemplo de teste do Apex usa a cláusula FOR VIEW antes de filtrar por LastViewedDate.
@isTest
public class AccountViewTest {
@testSetup
static void myTestSetup() {
Account a = new Account();
a.Name = 'Test Account';
insert a;
}
@isTest
static void testMethod1() {
List<Account> aForView = [Select Id, Name from Account LIMIT 1 FOR VIEW];
List<Account> a = [Select Id, Name from Account where LastViewedDate = TODAY LIMIT 1];
System.assertEquals(1, a.size());
}
}
Campos personalizados
- Para alterar o tipo de dados de um campo personalizado, use conjuntos de alterações. Porém, a implementação às vezes é atrasada, pois muitos registros são atualizados. Considere alterar o destino por meio da interface de usuário.
Objetos personalizados
- Você poderá encontrar um erro caso esteja implantando um conjunto de alterações com um objeto personalizado que tem um relacionamento do tipo pai e filho sem o campo mestre/detalhes no mesmo conjunto de alterações. Para resolver esse erro, inclua o campo personalizado mestre/detalhes no conjunto de alterações mesmo que não tenha alterado o padrão geral.
- Não há suporte à inserção de um objeto personalizado de forma simultânea à atualização do campo sharingModel de um objeto e à adição de uma nova regra de compartilhamento baseada em proprietário. Em vez disso, são necessárias três implantações separadas. Primeiro implemente o objeto personalizado, depois o sharingModel atualizado para o objeto e, então, a nova regra de compartilhamento baseadas em proprietário. Você pode atualizar o campo sharingModel e adicionar uma regra de compartilhamento de usuário convidado ou baseada em critérios em uma única implantação.
Fluxos
- Se você pretende implantar um fluxo com conjuntos de alterações, leve em conta as limitações do suporte à migração. Verifique se os fluxos fazem referência apenas aos campos e componentes disponíveis nos conjuntos de alterações.
- Você só pode incluir uma versão de um fluxo no conjunto de alterações.
- Se o fluxo não tiver nenhuma versão ativa ao carregar o conjunto de alterações externo, a versão mais recente inativa é usada.
- Ao exibir os componentes dependentes do conjunto de alterações, a página Dependências de componente lista as dependências de <i>todas</i> as versões do fluxo. Adicione todos os componentes interdependentes para a versão relevante do fluxo ao conjunto de alterações de saída.
- Um fluxo ativo em um conjunto de alterações é implantado no seu destino como inativo. Ative o fluxo manualmente após a implantação.
- A implantação ou reimplantação de um fluxo com conjuntos de alterações cria uma versão do fluxo no destino.
- Em organizações de produção, você pode habilitar a configuração para implementar uma nova versão ativa de um processo ou fluxo por meio de conjuntos de alterações ou API de metadados. A configuração não aparece em organizações não de produção (como organizações de teste, sandbox e desenvolvedor), pois você sempre pode implementar uma nova versão ativa.
Permissões
Consulte Conjuntos de permissões e configurações de perfil em conjuntos de alterações
Layout de página
Implantação que contém um perfil e tipo de registro, mas não o layout de página atribuído a esse tipo de registro, remove a atribuição de layout existente do perfil para esse tipo de registro. Sempre inclua todos os layouts de páginas para todos os tipos de registros necessários no conjunto de alterações.
Lista de opções
Os valores de um campo da lista de opções em um destino que não estão incluídos no conjunto de alterações são definidos como inativos.
Por exemplo, se a lista de opções de destino incluir um valor ativo de 1 e a lista de opções do conjunto de alterações não incluir 1 como valor, o 1 mudará de ativo para inativo no destino.
Compartilhamento
Não é possível atualizar o campo sharingModel referente a um objeto e, ao mesmo tempo, acrescentar uma nova regra de compartilhamento baseada em proprietário. É possível adicionar uma regra de compartilhamento baseada em proprietário quando o padrão geral é público e depois atualizar o sharingModel, o que resulta em um recálculo de compartilhamento único. É possível implantar uma regra de compartilhamento de usuário convidado ou baseada em critérios e alterações no campo sharingModel juntos usando componentes do conjunto de alterações.
API de metadados
Os comportamentos listados aqui se aplicam se você estiver usando Extensões do Salesforce para Visual Studio Code.
Classes do Apex e acionadores do Apex
Por padrão, as alterações feitas no Apex code que possui tarefas do Apex pendentes ou em andamento não podem ser implantadas. Para implementar essas alterações, siga uma destas etapas.
- Cancele as tarefas do Apex antes de implantar as alterações no Apex code. Reagende os trabalhos após a implementação.
- Ative as implantações com as tarefas do Apex na interface de usuário do Salesforce na página Configurações de implantação.
Se um registro for criado em um teste do Apex, o registro de teste não será marcado como visualizado. Portanto, os testes do Apex com consultas que filtram por LastViewedDate falham durante a implantação e podem causar falhas na cobertura de código. Para marcar um registro como visualizado em um teste do Apex, use primeiro a cláusula FOR VIEW e, em seguida, filtre por LastViewedDate.
Este exemplo de teste do Apex usa a cláusula FOR VIEW antes de filtrar por LastViewedDate.
@isTest
public class AccountViewTest {
@testSetup
static void myTestSetup() {
Account a = new Account();
a.Name = 'Test Account';
insert a;
}
@isTest
static void testMethod1() {
List<Account> aForView = [Select Id, Name from Account LIMIT 1 FOR VIEW];
List<Account> a = [Select Id, Name from Account where LastViewedDate = TODAY LIMIT 1];
System.assertEquals(1, a.size());
}
}
Processos de aprovação
- Para usar processos de aprovação em artigos do Salesforce Knowledge com a API de metadados, o tipo de artigo deve ser implantado. Para a versão de artigo (_kav) nos processos de aprovação, os tipos de ação suportados são: Ação de conhecimento, Alerta por email, Atualização de campo e Mensagem de saída.
- Se o processo de aprovação fizer referência a quaisquer modelos de publicação que contenham campos personalizados, salve novamente esses modelos na organização de origem antes de adicioná-los ao conjunto de alterações. Em Configuração, na caixa Busca rápida, insira Modelos de publicação e selecione Modelos de publicação. Para cada modelo de publicação, clique em Editar e em Salvar.
- Os metadados não incluem a ordem dos processos de aprovação ativos. Pode ser necessário reordenar os processos de aprovação no destino após a implementação.
- Se você alterar o Nome exclusivo de um processo de aprovação anteriormente incluído em um conjunto de alterações e implementado em outra organização e reenviar o processo de aprovação por meio de um conjunto de alterações, um novo processo de aprovação será criado na implementação da outra organização. O processo de aprovação implantado anteriormente não será modificado.
Provedores de autenticação
A partir de novembro de 2022, se um conjunto de alterações incluir um provedor de autenticação com um segredo do consumidor definido, o segredo do consumidor será alterado para um valor de espaço reservado. Você deve inserir o segredo do consumidor manualmente durante a implementação do conjunto de alterações.
Campos personalizados
A partir da API versão 30.0, ao implantar um novo campo personalizado, os valores padrão dos campos editáveis e legíveis nas permissões de campo do perfil são falsos. Para substituir os valores padrão, inclua permissões de campo referentes ao novo campo nos seus perfis.
Objetos personalizados
Não há suporte à inserção de um objeto personalizado de forma simultânea à atualização do campo sharingModel de um objeto e à adição de uma nova regra de compartilhamento baseada em proprietário. Em vez disso, são necessárias três implantações separadas. Primeiro implemente o objeto personalizado, depois o sharingModel atualizado para o objeto e, então, a nova regra de compartilhamento baseadas em proprietário. Você pode atualizar o campo sharingModel e adicionar uma regra de compartilhamento de usuário convidado ou baseada em critérios em uma única implantação.
Aplicativo conectado
- Não é possível configurar a consumerKey na API de metadados. Ela está incluída em uma operação de recuperação para fins informativos. Se você tentar mover o aplicativo conectado para outra organização, precisará remover a consumerKey do arquivo .zip antes da implantação em uma organização. Uma nova chave é gerada no destino.
- As configurações móveis de aplicativos conectados não têm suporte em conjuntos de alterações e devem ser migradas manualmente.
Grupos
Membros do grupo público não são migrados quando você implanta o tipo de grupo.
Relacionamentos entre mestre e detalhes
Uma implementação da API de metadados que inclua relacionamentos entre mestre e detalhes exclui todos os registros de detalhes da lixeira nestes casos.
- Para uma implantação com um novo campo Mestre e detalhes, exclua de forma não permanente (envie para a Lixeira) todos os registros de detalhes antes de continuar a implantação do campo Mestre e detalhes ou a implantação falhará. Durante a implantação, os registros de detalhes são excluídos permanentemente da Lixeira e não podem ser recuperados.
- Para uma implantação que converte um relacionamento de campo de pesquisa em um relacionamento entre mestre e detalhes, os registros de detalhes devem fazer referência a um registro mestre ou ser excluídos de forma não permanente (enviados para a Lixeira) para que a implantação dê certo. Porém, uma implementação bem-sucedida exclui permanentemente todos os registros de detalhes na Lixeira.
Layout de página
Uma implantação que contenha atribuições de layout de página substitui todas as atribuições de layout de página na organização de destino pelas atribuições especificadas no arquivo .zip. Os layouts de página existentes na organização desaparecerão se não estiverem incluídos no arquivo .zip. Sempre inclua todos os layouts de páginas para todos os tipos de registros necessários no arquivo .zip.
Lista de opções
Os valores de um campo da lista de opções em uma organização de destino que não estão incluídos nos metadados são definidos como inativos.
Por exemplo, se a organização de destino tiver uma lista de opções que inclua um valor ativo de 1 e os metadados não incluírem um valor da lista de opções de 1, o 1 mudará de ativo para inativo na organização de destino.
Perfis
Se um pacote incluir um perfil com um nome que não existe no destino, um novo perfil será criado com esse nome. Se o perfil implantado não especificar quaisquer permissões ou configurações, o perfil resultante consistirá em todas as permissões e configurações do Perfil padrão.
Os campos personalizados no objeto ContentVersion estão disponíveis a todos os usuários de perfil. Quando você exporta metadados de perfil, todos os campos personalizados são expostos.
Compartilhamento
- Usando a API versão 29.0, não é possível alterar o sharingModel de um objeto usando a API de metadados. Altere manualmente o destino por meio da interface de usuário.
- A partir da API versão 30.0, é possível alterar o sharingModel de um objeto para usuários internos usando a API de metadados e a interface do usuário.
- Não é possível atualizar o campo sharingModel referente a um objeto e, ao mesmo tempo, acrescentar uma nova regra de compartilhamento baseada em proprietário na API de metadados. É possível adicionar uma regra de compartilhamento baseada em proprietário quando o padrão geral é público e depois atualizar o sharingModel, o que resulta em um recálculo de compartilhamento único. É possível implantar uma regra de compartilhamento de usuário convidado ou baseada em critérios e alterações no campo sharingModel juntos usando a API de metadados.
Fluxo de trabalho
Não há suporte para o modo de teste para acionadores de fluxo na API de metadados. Se você deseja que um acionador de fluxo execute a versão mais recente do fluxo quando um administrador ativar a regra do fluxo de trabalho, ative o modo de teste por meio da interface do usuário depois da implantação.

