> For the complete documentation index, see [llms.txt](https://docs.flosum.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flosum.com/data-migrator/data-migrator-pt-br/modelos/designer-de-modelos/visao-geral-dos-modelos.md).
# Visão geral dos modelos
##  Visão geral
No Data Migrator, os modelos são a base da sua estratégia de migração de dados. Eles definem quais objetos serão migrados, preservam os relacionamentos entre registros, especificam quais campos incluir ou excluir e aplicam filtros para controlar quais dados são transferidos.
Os modelos são criados usando um Designer de Modelos visual que ajuda você a criar migrações de dados rapidamente. Antes de criar um modelo, entenda como os objetos se conectam entre si. Isso garante que seus registros migrados não deixem de fora dados críticos. Consulte a [#object-connections](#object-connections "mention") seção abaixo para obter detalhes.
#### Modelos
Para criar seu primeiro modelo, siga as instruções nos artigos listados abaixo.
* Recursos Básicos de Modelo
* [Criando um modelo](/data-migrator/data-migrator-pt-br/modelos/designer-de-modelos/criando-um-modelo.md)
* [Adicionando objetos a um modelo](/data-migrator/data-migrator-pt-br/modelos/designer-de-modelos/adicionando-objetos-a-um-modelo.md)
* [Adicionando campos aos objetos](/data-migrator/data-migrator-pt-br/modelos/designer-de-modelos/adicionando-campos-aos-objetos.md)
* [Preservando relacionamentos entre objetos](/data-migrator/data-migrator-pt-br/modelos/designer-de-modelos/preservando-relacionamentos-entre-objetos.md)
* Recursos Avançados de Modelo
* [Adicionando filtros aos objetos](/data-migrator/data-migrator-pt-br/modelos/designer-de-modelos/adicionando-filtros-aos-objetos.md)
* [Aplicando mascaramento de dados aos campos](/data-migrator/data-migrator-pt-br/modelos/designer-de-modelos/aplicando-mascaramento-de-dados-aos-campos.md)
* [Definindo limites de registros da migração](/data-migrator/data-migrator-pt-br/modelos/designer-de-modelos/definindo-limites-de-registros-da-migracao.md)
* [Definindo o mapeamento de registros do objeto](/data-migrator/data-migrator-pt-br/modelos/designer-de-modelos/definindo-o-mapeamento-de-registros-do-objeto.md)
#### Migração
Depois que seu modelo estiver concluído, você pode começar a migrar dados seguindo as instruções no artigo abaixo.
* [Visão geral da migração de dados](/data-migrator/data-migrator-pt-br/modelos/migracao/visao-geral-da-migracao-de-dados.md)
## Conexões entre Objetos
Em um Modelo, os objetos definem quais registros são transferidos entre orgs do Salesforce durante uma migração. Esta seção explica como os objetos em um modelo se conectam entre si.
### Conexão Pai-Filho
Ao migrar dados entre orgs do Salesforce, entender o relacionamento pai-filho entre objetos é crucial para manter a integridade dos dados. Em um Modelo do Data Migrator, esse relacionamento é visualizado como conexões entre objetos, permitindo um processo estruturado de mapeamento de dados. A visualização adequada dessas conexões ajuda a garantir que os registros relacionados sejam migrados sem erros.
* **Pai -> Filho** as conexões vão da parte inferior do objeto pai até o lado esquerdo do objeto filho.
* **Filho -> Pai** as conexões vão do lado direito do objeto filho até o topo do objeto pai.
A captura de tela abaixo mostra um modelo com vários objetos. Para cada objeto, os relacionamentos pai-filho com outros objetos estão descritos.
### Relacionamento Master-Detail
O **Master-Detail** ícone indica um relacionamento Master-Detail em que o objeto filho está fortemente vinculado e depende completamente do objeto pai. Nesse relacionamento, o registro pai controla determinados comportamentos do registro filho. Se um registro Master for excluído, todos os registros Detail relacionados serão excluídos automaticamente. Durante a migração de dados, você deve migrar os registros pai antes ou ao mesmo tempo que os registros filho para manter a integridade dos dados.
Por exemplo, se o objeto Customer Meetings tiver um relacionamento Master-Detail com o objeto Account, você deve migrar os registros de Account e Customer Meetings juntos. Isso garante que nenhum registro de Customer Meetings seja excluído se os registros de Account forem removidos da org de origem.
[Salesforce - Visão geral dos relacionamentos entre objetos](https://help.salesforce.com/s/articleView?id=platform.overview_of_custom_object_relationships.htm)
### Relacionamento de Consulta
O **Consulta** ícone indica um relacionamento de Consulta, em que o objeto filho faz referência ao objeto pai, mas não depende dele. Diferentemente dos relacionamentos Master-Detail, os relacionamentos de Consulta são mais frouxamente acoplados. Um registro filho pode fazer referência a um registro pai ou existir de forma independente, sem uma referência ao pai. Quando um registro pai é excluído, os registros filhos relacionados não são excluídos automaticamente.
Por exemplo, se o objeto Case tiver um relacionamento de Consulta com o objeto Account, os registros de Case podem existir com ou sem um registro de Account associado. Se o registro de Account relacionado for excluído, os registros de Case permanecem e não são removidos.
[Salesforce - Visão geral dos relacionamentos entre objetos](https://help.salesforce.com/s/articleView?id=platform.overview_of_custom_object_relationships.htm)
### Campo de Relacionamento
O **Campo de Relacionamento** é o campo que um registro filho usa para fazer referência ao seu registro pai. Ele aparece abaixo de cada objeto filho, com uma linha conectando-o ao seu pai correspondente. Na captura de tela abaixo, o **Customer Meetings** objeto tem dois Campos de Relacionamento.
* **CreatedById**: Conecta o **Customer Meetings** objeto ao **User** objeto em um relacionamento de Consulta.
* **Account\_\_c**: Conecta o **Customer Meetings** objeto ao **Account** objeto em um relacionamento Master-Detail.
{% hint style="warning" %}
#### Preservando relacionamentos
Para preservar o vínculo entre registros pai e filho durante a migração, os registros filho migrados devem incluir o **Campo de relacionamento** que os conecta ao seu pai. Isso se aplica tanto a relacionamentos Mestre-Detalhe quanto de Pesquisa. Para saber mais sobre isso, consulte o artigo a seguir.
* [Preservando relacionamentos entre objetos](/data-migrator/data-migrator-pt-br/modelos/designer-de-modelos/preservando-relacionamentos-entre-objetos.md)
{% endhint %}
## Mascaramento de Dados
O Mascaramento de Dados permite proteger campos sensíveis durante a migração, substituindo seus valores por dados aleatórios antes de serem gravados na organização de destino. Isso garante que ambientes de sandbox e teste mantenham estruturas de dados realistas para validação sem expor informações reais de clientes, ajudando sua equipe a permanecer em conformidade com os requisitos de privacidade de dados. Para saber mais sobre Mascaramento de Dados e como aplicá-lo a um campo específico, consulte o artigo a seguir.
* [Aplicando mascaramento de dados aos campos](/data-migrator/data-migrator-pt-br/modelos/designer-de-modelos/aplicando-mascaramento-de-dados-aos-campos.md)
## Configurações de Migração de Objetos
Cada objeto tem configurações individuais que controlam como ele é migrado. Use essas configurações para ajustar o comportamento da migração no nível do objeto, incluindo limites de registros e mapeamento de registros.
Para o objeto raiz de um modelo, você pode definir um limite para o número de registros raiz transferidos durante uma migração. Como o limite se aplica apenas aos registros raiz e os objetos filho migram seus próprios registros, o número total de registros migrados pode ser muito maior do que o limite definido. O artigo a seguir explica como essa configuração funciona e como ativá-la.
* [Definindo limites de registros da migração](/data-migrator/data-migrator-pt-br/modelos/designer-de-modelos/definindo-limites-de-registros-da-migracao.md)
O Data Migrator usa o mapeamento de registros para manter os registros precisos ao longo de várias execuções de migração. Quando você habilita o mapeamento de registros para um objeto, o Data Migrator mapeia registros individuais entre as organizações de origem e de destino, garantindo que as migrações subsequentes adicionem apenas novos registros e atualizem os existentes. Os artigos a seguir explicam como o mapeamento de registros funciona, descrevem as opções de mapeamento de registros disponíveis e fornecem instruções para ativá-lo.
* [Como o mapeamento de registros funciona](/data-migrator/data-migrator-pt-br/modelos/migracao/como-o-mapeamento-de-registros-funciona.md)
* [Definindo o mapeamento de registros do objeto](/data-migrator/data-migrator-pt-br/modelos/designer-de-modelos/definindo-o-mapeamento-de-registros-do-objeto.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.flosum.com/data-migrator/data-migrator-pt-br/modelos/designer-de-modelos/visao-geral-dos-modelos.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
O **Master-Detail** ícone indica um relacionamento Master-Detail em que o objeto filho está fortemente vinculado e depende completamente do objeto pai. Nesse relacionamento, o registro pai controla determinados comportamentos do registro filho. Se um registro Master for excluído, todos os registros Detail relacionados serão excluídos automaticamente. Durante a migração de dados, você deve migrar os registros pai antes ou ao mesmo tempo que os registros filho para manter a integridade dos dados.
Por exemplo, se o objeto Customer Meetings tiver um relacionamento Master-Detail com o objeto Account, você deve migrar os registros de Account e Customer Meetings juntos. Isso garante que nenhum registro de Customer Meetings seja excluído se os registros de Account forem removidos da org de origem.
[Salesforce - Visão geral dos relacionamentos entre objetos](https://help.salesforce.com/s/articleView?id=platform.overview_of_custom_object_relationships.htm)
### Relacionamento de Consulta 
O **Consulta** ícone indica um relacionamento de Consulta, em que o objeto filho faz referência ao objeto pai, mas não depende dele. Diferentemente dos relacionamentos Master-Detail, os relacionamentos de Consulta são mais frouxamente acoplados. Um registro filho pode fazer referência a um registro pai ou existir de forma independente, sem uma referência ao pai. Quando um registro pai é excluído, os registros filhos relacionados não são excluídos automaticamente.
Por exemplo, se o objeto Case tiver um relacionamento de Consulta com o objeto Account, os registros de Case podem existir com ou sem um registro de Account associado. Se o registro de Account relacionado for excluído, os registros de Case permanecem e não são removidos.
[Salesforce - Visão geral dos relacionamentos entre objetos](https://help.salesforce.com/s/articleView?id=platform.overview_of_custom_object_relationships.htm)
### Campo de Relacionamento
O **Campo de Relacionamento** é o campo que um registro filho usa para fazer referência ao seu registro pai. Ele aparece abaixo de cada objeto filho, com uma linha conectando-o ao seu pai correspondente. Na captura de tela abaixo, o **Customer Meetings** objeto tem dois Campos de Relacionamento.
* **CreatedById**: Conecta o **Customer Meetings** objeto ao **User** objeto em um relacionamento de Consulta.
* **Account\_\_c**: Conecta o **Customer Meetings** objeto ao **Account** objeto em um relacionamento Master-Detail.
