Propriedade e ciclo de vida

🌐 Também em 28 idiomas

English · Español · 日本語 · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Imagem gerada com IA

Traduzido por IA. Ainda não revisado pela comunidade. Ler em inglês

Módulo 8 de 10 do capítulo Arquitetura de dados Salesforce, capítulo 3 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Relacionamentos têm consequências · Próximo: Mantendo os dados consistentes

A pergunta que este módulo responde: Quem é dono do registro, e o que acontece com ele ao longo da vida?

Quando olho para um modelo de dados, não quero saber só quais são os objetos e como se conectam. Quero saber o que acontece com os registros ao longo do tempo. Quem os cria? Quem é dono deles? Quem pode reatribuí-los? O que acontece quando o relacionamento de negócio muda, quando eles deixam de estar ativos? Deveriam algum dia ser excluídos, e por quanto tempo os guardamos? Nada disso aparece num DER, o diagrama entidade-relacionamento: as caixas e linhas do modelo de dados do capítulo 2. Tudo isso é arquitetura de dados. E, no Salesforce, a propriedade é onde o modelo de dados e o modelo de segurança se trombam.

Propriedade é mais que um nome num campo

Os administradores veem Proprietário num registro e o leem como um rótulo: o Bart é dono desta conta, a Lisa é dona daquele caso. Pode significar isso. Mas, no Salesforce, a propriedade também é um mecanismo da plataforma. Em objetos que têm proprietário, ele determina quem consegue ver o registro, pela hierarquia de papéis, pelas regras de compartilhamento, pelas filas e pela reatribuição. Então, quando pergunto “quem é dono deste registro?”, não estou perguntando de quem é o nome que vai na página. Estou perguntando que comportamento de segurança e de ciclo de vida estamos atrelando a ele. O proprietário pode ser um usuário ou, em alguns objetos, entre eles objetos personalizados, casos e leads, uma fila, e de qualquer forma o proprietário recebe acesso total ao registro (Understanding Sharing (opens in a new tab), em inglês).

É por isso que separo responsabilidade de negócio de propriedade do registro. Às vezes são a mesma pessoa. Às vezes não. Se o negócio diz que um despachante é responsável por uma entrega, isso não torna o despachante automaticamente o proprietário. A responsabilidade pode viver num campo próprio enquanto a propriedade é definida para sustentar a segurança e a escala. Não deixe as duas se confundirem só porque ambas usam a palavra “dono”.

A tabela de compartilhamento: onde a propriedade vira acesso

Tem gente que nem sabe o que é a tabela de compartilhamento. Todo arquiteto de dados deveria saber.

A maior parte do compartilhamento de um registro fica guardada num objeto de compartilhamento (share object) relacionado, a versão do Salesforce de uma lista de controle de acesso (Understanding Sharing (opens in a new tab), em inglês). A Conta tem AccountShare, o Contato tem ContactShare, e um objeto personalizado ganha o seu: Truck__c tem Truck__Share (Sharing a Record Using Apex (opens in a new tab), em inglês). Cada linha nele diz quatro coisas:

• Qual registro: o ID do pai.
• Quem: um usuário, ou um grupo (um grupo público, o grupo de um papel, um território).
• Quanto: Read, Edit ou All (leitura, edição ou acesso total).
• Por quê: o motivo da linha (row cause). Owner para o proprietário, Rule para uma regra de compartilhamento, Manual para um compartilhamento manual, Team, os motivos implícitos que o Salesforce acrescenta entre uma conta e seus filhos, e motivos que um desenvolvedor define para o compartilhamento via Apex.

Em aula abro o Workbench e consulto a tabela de compartilhamento enquanto compartilho um registro, e você vê as linhas aparecerem e sumirem. Quando alguém pergunta “por que essa pessoa consegue ver aquilo?”, a resposta muitas vezes está numa linha, com o motivo dela.

Mas nem tudo está lá. O padrão para toda a organização não é uma linha. A hierarquia de papéis também não fica guardada ali: o acesso de quem está acima do proprietário é calculado quando é preciso. E View All, Modify All, View All Data e Modify All Data pulam a tabela de compartilhamento por completo (Sharing a Record Using Apex (opens in a new tab), em inglês). Como digo em aula: marcou View All, passou por cima da tabela de compartilhamento.

O Salesforce também compartilha alguns registros por você, por causa de como eles se relacionam. Isso é o compartilhamento implícito, e ele funciona entre uma conta e seus filhos. Se você consegue ver um contato, um caso ou uma oportunidade, também consegue ler a conta a que ele pertence. E o proprietário da conta recebe acesso aos contatos, casos e oportunidades da conta, num nível definido pelo papel do proprietário (Implicit Sharing (opens in a new tab), em inglês). Nas versões recentes, o Salesforce calcula parte desse acesso aos filhos quando é preciso, em vez de guardá-lo como linhas, então não se surpreenda quando uma consulta à tabela de compartilhamento não o mostrar. Aqui só estou lhe dando uma pista; os detalhes estão em Relacionamentos e compartilhamento nativo.

Mais uma exceção, para quando você tem muitos usuários externos. Os usuários de comunidade de alto volume (high-volume community users), as licenças Customer Community feitas para milhares a milhões de clientes, não têm papel, não podem estar em grupos públicos e não podem receber registros por regras de compartilhamento nem por compartilhamento manual (About High-Volume Community or Site Users (opens in a new tab); Sharing Rule Considerations (opens in a new tab), em inglês). Para eles, a tabela de compartilhamento não é a resposta: eles chegam aos registros por conjuntos de compartilhamento, que fazem a correspondência entre a conta ou o contato de um registro e os do próprio usuário. É um dos motivos pelos quais essas licenças escalam. O curso de Compartilhamento e Visibilidade trata disso em Compartilhando com usuários externos.

E lembre-se do módulo 7: um objeto de detalhe não tem objeto de compartilhamento nenhum. O acesso dele vem do objeto de compartilhamento do mestre e da Sharing Setting no campo mestre-detalhes.

Por que um arquiteto de dados se importa? Porque a propriedade fica escrita nessa tabela. Toda troca de proprietário, toda nova regra de compartilhamento, todo usuário que muda de papel ou de grupo significa o Salesforce acrescentando e removendo linhas. Com alguns milhares de registros ninguém percebe. Com dez milhões, e um único usuário dono da maioria deles, é o recálculo que vamos encontrar daqui a pouco.

Conhecimento para o exame. O objeto de compartilhamento de um objeto personalizado se chama Object__Share, como Truck__Share. Um objeto de detalhe não tem objeto de compartilhamento: o acesso dele vem do mestre. E quando o proprietário de um registro muda, os compartilhamentos manuais dele são removidos, enquanto o compartilhamento via Apex com um motivo definido pelo desenvolvedor permanece.

É aqui que o modelo de dados passa o bastão para o modelo de segurança, e eu ensino o resto no curso Sharing and Visibility Architect: As 22 formas de compartilhar um registro, segundo Steve, Padrões para toda a organização, propriedade, filas e hierarquia de papéis, Relacionamentos e compartilhamento nativo para os compartilhamentos implícitos, e Compartilhamento programático e código seguro para os motivos de compartilhamento via Apex. Neste curso, o capítulo 12 junta tudo isso para humanos, aplicações e agentes.

Às vezes a propriedade é herdada

No último módulo vimos que um filho mestre-detalhes não tem proprietário próprio; ele segue o pai. Muitas vezes isso está exatamente certo. O negócio precisa de um proprietário diferente para cada item de uma entrega? Não. A entrega é dona do ciclo de vida e o item pertence a ela. É por isso que o design de relacionamentos e o design de propriedade acontecem juntos: quando você escolheu mestre-detalhes, já tinha tomado parte da decisão de propriedade.

Quem é dono dos registros que os sistemas criam?

Agora fica interessante. Uma pessoa cria uma conta, e talvez vire a proprietária. Mas um ERP envia 100 mil transações durante a noite. Quem é dono delas? O usuário de integração? Uma fila? Um proprietário regional deduzido dos dados? Uma conta de sistema em que ninguém pensa há cinco anos? E agora os agentes também criam registros.

Minha posição: depende de a propriedade importar ou não para o compartilhamento. O usuário de integração, ou o usuário do agente, é um usuário válido, e pode ser dono dos registros. Se a propriedade determina o acesso naquele objeto (pela hierarquia de papéis ou pelas regras de compartilhamento), atribua os registros ao proprietário certo: um usuário real, uma fila, ou um usuário proprietário dedicado. Se não determina, manter o usuário de sistema como proprietário pode ser a melhor escolha, porque aí a trilha de auditoria leva direto de volta ao que criou o registro.

De qualquer forma, decida de propósito. Uma conta de integração que é dona de tudo virou em silêncio parte da sua arquitetura de segurança, e alguém precisa saber o que acontece se ela for desativada algum dia.

A propriedade pode virar um problema de escala

A distribuição também importa. Dez milhões de registros espalhados entre milhares de proprietários é uma forma. Dez milhões de registros de um único usuário é outra bem diferente. A Salesforce chama de desequilíbrio de propriedade dos dados (ownership data skew) quando um único usuário é dono de mais de 10 mil registros de um objeto (Ownership Data Skew (opens in a new tab), em inglês). Normalmente acontece quando alguém estaciona tudo num usuário ou numa fila: todos os leads não atribuídos num usuário reservado, todo registro de integração no usuário de integração. É inofensivo até esse usuário mudar de lugar na hierarquia de papéis, ou entrar ou sair de um grupo do qual uma regra de compartilhamento depende. Aí o Salesforce precisa ajustar um número enorme de entradas de compartilhamento, e você ganha recálculos demorados.

A orientação é prática. Espalhe a propriedade entre mais usuários onde puder. Se um usuário precisa ser dono de muita coisa, mantenha-o fora da hierarquia de papéis; se ele precisa de um papel, coloque-o num papel próprio no topo e não o mova, e mantenha-o fora dos grupos públicos que as regras de compartilhamento usam (Ownership Data Skew (opens in a new tab), em inglês). O mesmo raciocínio vale para o pai com filhos demais do último módulo, o desequilíbrio pai-filho.

Então a distribuição faz parte do modelo físico. Não pergunte só quantos registros; pergunte como estão distribuídos. É outra versão do Número de Zeros: não só quantos zeros, mas onde os zeros se concentram. A Parte 2 vai fundo no desequilíbrio; aqui quero que você o veja chegando. O curso de Compartilhamento e Visibilidade retoma o assunto em Compartilhamento em escala.

O “proprietário padrão” vira arquitetura

Eis um padrão que vejo o tempo todo. Ninguém sabe quem deveria ser dono de algo, então alguém diz: “Atribua tudo ao usuário de integração”, ou “crie um usuário genérico chamado Sistema”. Talvez esteja certo. Mas não faça isso por acidente. Um padrão temporário tem o hábito de virar permanente: dois anos depois todo registro pertence a integration@company.com, ninguém lembra por quê, e mudar isso é um projeto. É o Teste de Reversibilidade do capítulo 1: antes de dar um milhão de registros a um proprietário, pergunte o que custa mudar isso depois.

A reatribuição é um evento do ciclo de vida

Os proprietários mudam. Vendedores saem, territórios mudam, equipes se reorganizam, regiões são rebalanceadas. O que depende do proprietário: compartilhamento, automação, relatórios, filas, escalonamentos, integrações? Se mudar o proprietário muda quem consegue ver o registro, a reatribuição não é faxina de administrador. É um evento de segurança, e com um milhão de registros é também um evento operacional. Observe a tabela de compartilhamento quando isso acontece: os compartilhamentos manuais são removidos quando o proprietário muda, enquanto o compartilhamento via Apex com um motivo definido pelo desenvolvedor sobrevive à mudança (Understanding Sharing (opens in a new tab), em inglês). Em aula compartilho um registro com alguém, troco o proprietário, e a pessoa perde o acesso. A sala sempre se surpreende.

E lembre-se de que propriedade não é a mesma coisa que acesso. O proprietário não é a única pessoa que precisa ver um registro, e o Salesforce tem muitas formas de conceder acesso: a hierarquia de papéis, regras de compartilhamento, equipes, territórios, compartilhamento manual e programático. O curso de Compartilhamento e Visibilidade vai fundo nisso, começando por As 22 formas de compartilhar um registro, segundo Steve. O ponto do arquiteto é mais simples: não use a propriedade para resolver todo problema de acesso. Se você está trocando proprietários só para que alguém consiga ver um registro, provavelmente está resolvendo o problema errado.

A criação é só o começo

Muita modelagem de dados para na criação: os campos, o objeto, o relacionamento, pronto. Mas o registro pode viver dez anos. Ele é atualizado, troca de proprietário, muda de status e de relacionamentos, fica inativo, vira histórico, pode precisar ser arquivado e, um dia, talvez excluído. A arquitetura não é só como o registro nasce. É o que acontece do nascimento à morte.

Click to enlarge

Não exclua só porque algo é antigo

Um Parceiro varejista para de enviar trabalho. Excluir a conta? Não automaticamente: suas entregas, reclamações e histórico de faturamento ainda importam. Um caminhão é aposentado. Excluí-lo, junto com o histórico de entregas e as reclamações de avaria? A coisa pode não estar mais ativa, mas seus dados continuam. Por isso separo inativo de sumido. Um caminhão aposentado pode continuar no modelo; um ex-funcionário ainda pode aparecer no histórico de auditoria. A arquitetura precisa manter os fatos que importam depois que o relacionamento operacional termina.

A retenção é um requisito de negócio

O outro lado: guardar tudo para sempre também não é arquitetura. O armazenamento cresce, os relatórios ficam lentos, a busca fica mais ruidosa, e a lei de privacidade pode dizer que alguns dados precisam sair. Então quero uma resposta explícita para por quanto tempo guardamos isto? “O Salesforce guarda” não é uma política de retenção.

E, na maioria das vezes, essa é uma pergunta sobre dados transacionais. Os dados de referência, os produtos, os tipos de serviço, os centros de distribuição, não ficam enormes, e outros registros apontam para eles, então eles geralmente ficam. Os dados de cliente estão no meio: pode chegar o dia em que você encerra o ciclo de vida de um cliente, especialmente quando guarda dados pessoais e o motivo para guardá-los acaba. Mas o volume está nas transações: as entregas, os pedidos, os casos, os compromissos, criados todo dia, para sempre. É isso que cresce até centenas de milhões de linhas, e é aí que a retenção tem de ser explícita: talvez dois anos de dados operacionais na org, sete anos de registros financeiros em algum lugar, noventa dias para algumas fotos. Essas são regras de negócio, e se ninguém perguntou, o arquiteto deve perguntar.

Digo isto em aula há anos: se você não arquiva hoje, algum dia vai arquivar? “Vemos isso depois” tem o hábito de virar um projeto de emergência com trezentos milhões de registros. A Parte 2 tem um módulo inteiro sobre arquivamento e expurgo, construído sobre a mesma pergunta.

Steve Trucking: quem é dono de uma entrega?

Uma entrega é criada a partir do manifesto do Parceiro varejista, por uma integração, umas 3.300 vezes por dia. Quem é dono dela? Não o Parceiro varejista; isso é um relacionamento de negócio. Não o Destinatário. A equipe a executa, mas o registro deveria mudar de proprietário toda vez que as equipes trocam de caminhão? O despachante? O centro de distribuição? Uma fila? O usuário de integração que a criou?

Agora aplique este módulo, começando pela pergunta que decide tudo: a propriedade determina o acesso de alguém às entregas? Na Steve Trucking, não. Os despachantes veem as entregas do seu centro de distribuição, as equipes veem as das suas rotas, e cada varejista vê as suas no portal do parceiro. Nada disso depende de quem é dono do registro; vem do centro de distribuição, da rota e do parceiro.

Então minha resposta: o usuário de integração é dono das entregas. É um bom exemplo de um usuário de sistema que é dono de registros de propósito:

• A trilha de auditoria é honesta. O proprietário de cada entrega diz de onde ela veio: a integração do manifesto.
• O acesso vem do compartilhamento, não da propriedade. Regras de compartilhamento baseadas em critérios no centro de distribuição dão à equipe de cada CD as suas entregas; os parceiros chegam às deles pelo portal.
• O desequilíbrio fica de fora do design. Com 3.300 por dia, o usuário de integração passa de 10 mil entregas em três dias, então é desequilíbrio de propriedade desde o primeiro dia, e tudo bem se planejarmos para isso. O usuário de integração não tem papel, então nada acima dele numa hierarquia precisa ser recalculado, e ele fica fora dos grupos públicos que as nossas regras de compartilhamento usam.
• Ninguém reatribui entregas. As equipes trocam de caminhão e os despachantes mudam de turno, e o proprietário nunca muda, então não há tempestade de reatribuições nem compartilhamentos manuais para perder.

E anote o que acontece se esse usuário algum dia for desativado ou substituído, porque agora ele é dono de milhões de registros. Essa é a decisão que a próxima equipe vai precisar encontrar.

Além do exame: o que a IA muda. Os agentes criam e alteram registros em velocidade de máquina. Se um agente cria 100 mil registros com seu próprio usuário, “depois arrumamos o proprietário” vira desequilíbrio, um recálculo de compartilhamento e um projeto de limpeza. Decida a regra de propriedade do agente antes de ele entrar em produção, com a mesma pergunta: a propriedade importa para o compartilhamento aqui?

O que um arquiteto decide aqui

• Se a propriedade representa responsabilidade de negócio, um mecanismo de segurança ou ambos, e onde a responsabilidade vive se não for no Proprietário.
• Se os registros precisam de proprietário próprio ou devem herdá-lo de um pai.
• Quem é dono dos registros que integrações e agentes criam, dependendo de a propriedade determinar ou não o compartilhamento.
• Como a propriedade é distribuída, e como evitar o desequilíbrio de propriedade quando um usuário precisa ser dono de muita coisa.
• Quando os registros ficam inativos, quando são arquivados, por quanto tempo são guardados, e quando a exclusão é a coisa certa.

Quando olhar para um modelo físico, não pergunte só onde os dados estão armazenados. Pergunte quem é dono deles hoje, quem pode ser dono amanhã, e o que acontece quando não precisarmos mais deles. A seguir: mesmo com o objeto, os campos, os relacionamentos e o proprietário certos, os dados ainda precisam continuar confiáveis.

Para saber mais

• Apex Developer Guide, Understanding Sharing (opens in a new tab) (em inglês), consultado em 2026-10-13: os proprietários (um usuário, ou uma fila para objetos personalizados, casos e leads) recebem acesso total; a maior parte do compartilhamento fica num objeto de compartilhamento relacionado; a hierarquia de papéis é calculada em tempo de execução; os compartilhamentos manuais são removidos quando o proprietário muda, e o compartilhamento gerenciado via Apex é mantido; os valores de motivo da linha (row cause).
• Apex Developer Guide, Sharing a Record Using Apex (opens in a new tab) (em inglês), consultado em 2026-10-13: AccountShare, MyCustomObject__Share; objetos de detalhe não têm objeto de compartilhamento; o que o objeto de compartilhamento não registra (padrão para toda a organização, hierarquia de papéis, View All e Modify All).
• Salesforce Help, Implicit Sharing (opens in a new tab) (em inglês), consultado em 2026-10-13: o acesso entre uma conta e seus contatos, casos e oportunidades.
• Salesforce Help, About High-Volume Community or Site Users (opens in a new tab) e Sharing Rule Considerations (opens in a new tab) (em inglês), consultados em 2026-10-13: sem papéis, sem regras de compartilhamento nem compartilhamentos manuais; conjuntos de compartilhamento no lugar.
• Curso Sharing and Visibility Architect: As 22 formas de compartilhar um registro, segundo Steve, Padrões para toda a organização, propriedade, filas e hierarquia de papéis, Relacionamentos e compartilhamento nativo, Compartilhamento programático e código seguro, Compartilhando com usuários externos, Compartilhamento em escala.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (opens in a new tab) e Parent-Child Data Skew (opens in a new tab) (em inglês), consultados em 2026-10-02.