Propriedade e ciclo de vida

🌐 Também em 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · 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 com IA. Ainda não revisto 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 sustenta-se sozinho. Anterior: As relações têm consequências · Próximo: Manter os dados consistentes

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

Quando olho para um modelo de dados, não quero saber só quais são os objetos e como se ligam. Quero saber o que acontece aos registos ao longo do tempo. Quem os cria? Quem é dono deles? Quem os pode reatribuir? O que acontece quando a relação de negócio muda, quando deixam de estar ativos? Deveriam alguma vez ser eliminados, e durante quanto tempo os guardamos? Nada disto aparece num DER, o diagrama entidade-relação: as caixas e linhas do modelo de dados do capítulo 2. Tudo isto é arquitetura de dados. E, no Salesforce, a propriedade é onde o modelo de dados e o modelo de segurança chocam.

A propriedade é mais do que um nome num campo

Os administradores veem Proprietário num registo e leem-no 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 registo, através da hierarquia de funções, das regras de partilha, das filas e da reatribuição. Por isso, quando pergunto «quem é dono deste registo?», não estou a perguntar de quem é o nome que vai na página. Estou a perguntar que comportamento de segurança e de ciclo de vida lhe estamos a associar. O proprietário pode ser um utilizador ou, em alguns objetos, entre eles os objetos personalizados, os casos e as leads, uma fila, e de qualquer forma o proprietário recebe acesso total ao registo (Understanding Sharing (opens in a new tab), em inglês).

É por isso que separo responsabilidade de negócio de propriedade do registo. Às vezes são a mesma pessoa. Às vezes não. Se o negócio diz que um expedidor é responsável por uma entrega, isso não faz do expedidor 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 confundirem-se só porque ambas usam a palavra «dono».

A tabela de partilha: onde a propriedade se torna acesso

Há quem nem sequer saiba o que é a tabela de partilha. Todos os arquitetos de dados deviam saber.

A maior parte da partilha de um registo fica guardada num objeto de partilha (share object) relacionado, a versão do Salesforce de uma lista de controlo de acesso (Understanding Sharing (opens in a new tab), em inglês). A Conta tem AccountShare, o Contacto 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:

• Que registo: o ID do pai.
• Quem: um utilizador, ou um grupo (um grupo público, o grupo de uma função, um território).
• Quanto: Read, Edit ou All (leitura, edição ou acesso total).
• Porquê: o motivo da linha (row cause). Owner para o proprietário, Rule para uma regra de partilha, Manual para uma partilha manual, Team, os motivos implícitos que o Salesforce acrescenta entre uma conta e os seus filhos, e motivos que um programador define para a partilha via Apex.

Nas aulas abro o Workbench e consulto a tabela de partilha enquanto partilho um registo, e vê as linhas a aparecer e a desaparecer. Quando alguém pergunta «porque é que esta pessoa consegue ver aquilo?», a resposta está muitas vezes numa linha, com o seu motivo.

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

O Salesforce também partilha alguns registos por si, por causa da forma como se relacionam. É a partilha implícita, e funciona entre uma conta e os seus filhos. Se consegue ver um contacto, um caso ou uma oportunidade, também consegue ler a conta a que pertence. E o proprietário da conta recebe acesso aos contactos, casos e oportunidades da conta, num nível definido pela função 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 o guardar como linhas, por isso não se surpreenda quando uma consulta à tabela de partilha não o mostrar. Aqui só lhe estou a dar uma pista; os pormenores estão em Relações e partilha nativa.

Mais uma exceção, para quando tem muitos utilizadores externos. Os utilizadores 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 função, não podem estar em grupos públicos e não podem receber registos através de regras de partilha nem de partilha 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 partilha não é a resposta: chegam aos registos através de conjuntos de partilha, que fazem a correspondência entre a conta ou o contacto de um registo e os do próprio utilizador. É um dos motivos pelos quais essas licenças escalam. O curso de Partilha e Visibilidade trata disso em Partilhar com utilizadores externos.

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

Porque é que um arquiteto de dados se importa? Porque a propriedade fica escrita nesta tabela. Cada mudança de proprietário, cada nova regra de partilha, cada utilizador que muda de função ou de grupo significa o Salesforce a acrescentar e a remover linhas. Com alguns milhares de registos ninguém repara. Com dez milhões, e um único utilizador dono da maioria deles, é o recálculo que vamos encontrar daqui a pouco.

Conhecimento para o exame. O objeto de partilha de um objeto personalizado chama-se Object__Share, como Truck__Share. Um objeto de detalhe não tem objeto de partilha: o seu acesso vem do mestre. E quando o proprietário de um registo muda, as suas partilhas manuais são removidas, enquanto a partilha via Apex com um motivo definido pelo programador se mantém.

É aqui que o modelo de dados passa o testemunho ao modelo de segurança, e eu ensino o resto no curso Sharing and Visibility Architect: As 22 formas de partilhar um registo, segundo o Steve, Padrões para toda a organização, propriedade, filas e hierarquia de funções, Relações e partilha nativa para as partilhas implícitas, e Partilha programática e código seguro para os motivos de partilha via Apex. Neste curso, o capítulo 12 junta tudo isto para humanos, aplicações e agentes.

Às vezes a propriedade é herdada

No último módulo vimos que um filho mestre-detalhe não tem proprietário próprio; 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-lhe. É por isso que o design de relações e o design de propriedade acontecem juntos: quando escolheu mestre-detalhe, já tinha tomado parte da decisão de propriedade.

Quem é dono dos registos que os sistemas criam?

Agora fica interessante. Uma pessoa cria uma conta, e talvez se torne a proprietária. Mas um ERP envia 100 mil transações durante a noite. Quem é dono delas? O utilizador 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 registos.

A minha posição: depende de a propriedade importar ou não para a partilha. O utilizador de integração, ou o utilizador do agente, é um utilizador válido, e pode ser dono dos registos. Se a propriedade determina o acesso naquele objeto (através da hierarquia de funções ou das regras de partilha), atribua os registos ao proprietário certo: um utilizador real, uma fila, ou um utilizador proprietário dedicado. Se não determina, manter o utilizador de sistema como proprietário pode ser a melhor escolha, porque aí o registo de auditoria leva diretamente ao que criou o registo.

Seja como for, decida de propósito. Uma conta de integração que é dona de tudo passou em silêncio a fazer parte da sua arquitetura de segurança, e alguém precisa de saber o que acontece se ela alguma vez for desativada.

A propriedade pode tornar-se um problema de escala

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

A orientação é prática. Espalhe a propriedade por mais utilizadores onde puder. Se um utilizador tem de ser dono de muita coisa, mantenha-o fora da hierarquia de funções; se precisa de uma função, ponha-o numa função própria no topo e não o mova, e mantenha-o fora dos grupos públicos que as regras de partilha usam (Ownership Data Skew (opens in a new tab), em inglês). O mesmo raciocínio vale para o pai com filhos a mais do último módulo, o desequilíbrio pai-filho.

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

O «proprietário por defeito» torna-se arquitetura

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

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

Os proprietários mudam. Os comerciais saem, os territórios mudam, as equipas reorganizam-se, as regiões são reequilibradas. O que depende do proprietário: partilha, automação, relatórios, filas, escalamentos, integrações? Se mudar o proprietário muda quem consegue ver o registo, a reatribuição não é arrumação de administrador. É um evento de segurança, e com um milhão de registos é também um evento operacional. Observe a tabela de partilha quando isso acontece: as partilhas manuais são removidas quando o proprietário muda, enquanto a partilha via Apex com um motivo definido pelo programador sobrevive à mudança (Understanding Sharing (opens in a new tab), em inglês). Nas aulas partilho um registo com alguém, troco o proprietário, e a pessoa perde o acesso. A sala surpreende-se sempre.

E lembre-se de que propriedade não é o mesmo que acesso. O proprietário não é a única pessoa que precisa de ver um registo, e o Salesforce tem muitas formas de conceder acesso: a hierarquia de funções, regras de partilha, equipas, territórios, partilha manual e programática. O curso de Partilha e Visibilidade vai a fundo nisto, a começar por As 22 formas de partilhar um registo, segundo o Steve. O ponto do arquiteto é mais simples: não use a propriedade para resolver todos os problemas de acesso. Se está a trocar proprietários só para que alguém consiga ver um registo, provavelmente está a resolver o problema errado.

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

Muita modelação de dados fica pela criação: os campos, o objeto, a relação, pronto. Mas o registo pode viver dez anos. É atualizado, muda de proprietário, muda de estado e de relações, fica inativo, passa a histórico, pode ter de ser arquivado e, um dia, talvez eliminado. A arquitetura não é só como nasce o registo. É o que acontece do nascimento à morte.

Click to enlarge

Não elimine só porque algo é antigo

Um Parceiro retalhista deixa de enviar trabalho. Eliminar a conta? Não automaticamente: as suas entregas, reclamações e histórico de faturação continuam a importar. Um camião é retirado. Eliminá-lo, juntamente com o histórico de entregas e as reclamações por danos? A coisa pode já não estar ativa, mas os seus dados continuam. Por isso separo inativo de desaparecido. Um camião retirado pode continuar no modelo; um ex-colaborador pode continuar a aparecer no histórico de auditoria. A arquitetura tem de manter os factos que importam depois de a relação operacional terminar.

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 pesquisa fica mais ruidosa, e a lei de privacidade pode dizer que alguns dados têm de sair. Por isso quero uma resposta explícita para durante quanto tempo guardamos isto? «O Salesforce guarda» não é uma política de retenção.

E, na maioria das vezes, esta é 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 registos apontam para eles, por isso normalmente ficam. Os dados de cliente estão no meio: pode chegar o dia em que encerra o ciclo de vida de um cliente, sobretudo quando guarda dados pessoais e o motivo para os guardar acaba. Mas o volume está nas transações: as entregas, as encomendas, os casos, as marcações, criados todos os dias, 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 registos financeiros noutro sítio, noventa dias para algumas fotografias. São regras de negócio, e se ninguém perguntou, o arquiteto deve perguntar.

Digo isto nas aulas há anos: se não arquiva hoje, alguma vez vai arquivar? «Vemos isso depois» tem o hábito de se transformar num projeto de emergência com trezentos milhões de registos. A Parte 2 tem um módulo inteiro sobre arquivo e expurgo, construído sobre a mesma pergunta.

Steve Trucking: quem é dono de uma entrega?

Uma entrega é criada a partir do manifesto do Parceiro retalhista, por uma integração, umas 3.300 vezes por dia. Quem é dono dela? Não o Parceiro retalhista; isso é uma relação de negócio. Não o Destinatário. A equipa executa-a, mas o registo deveria mudar de proprietário sempre que as equipas trocam de camião? O expedidor? O centro de distribuição? Uma fila? O utilizador de integração que a criou?

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

Por isso a minha resposta: o utilizador de integração é dono das entregas. É um bom exemplo de um utilizador de sistema que é dono de registos de propósito:

• O registo de auditoria é honesto. O proprietário de cada entrega diz de onde ela veio: a integração do manifesto.
• O acesso vem da partilha, não da propriedade. Regras de partilha baseadas em critérios no centro de distribuição dão à equipa de cada CD as suas entregas; os parceiros chegam às deles através do portal.
• O desequilíbrio fica de fora do design. Com 3.300 por dia, o utilizador de integração passa das 10 mil entregas em três dias, por isso há desequilíbrio de propriedade desde o primeiro dia, e não faz mal se o planearmos. O utilizador de integração não tem função, por isso nada acima dele numa hierarquia tem de ser recalculado, e fica fora dos grupos públicos que as nossas regras de partilha usam.
• Ninguém reatribui entregas. As equipas trocam de camião e os expedidores mudam de turno, e o proprietário nunca muda, por isso não há tempestade de reatribuições nem partilhas manuais a perder.

E registe por escrito o que acontece se esse utilizador alguma vez for desativado ou substituído, porque agora é dono de milhões de registos. É essa a decisão que a próxima equipa vai precisar de encontrar.

Além do exame: o que a IA muda. Os agentes criam e alteram registos à velocidade da máquina. Se um agente cria 100 mil registos com o seu próprio utilizador, «depois arrumamos o proprietário» transforma-se em desequilíbrio, num recálculo de partilha e num projeto de limpeza. Decida a regra de propriedade do agente antes de ele entrar em produção, com a mesma pergunta: a propriedade importa aqui para a partilha?

O que um arquiteto decide aqui

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

Quando olhar para um modelo físico, não pergunte só onde estão armazenados os dados. Pergunte quem é dono deles hoje, quem pode ser dono amanhã, e o que acontece quando já não precisarmos deles. A seguir: mesmo com o objeto, os campos, as relações e o proprietário certos, os dados continuam a ter de se manter fiá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 utilizador, ou uma fila para objetos personalizados, casos e leads) recebem acesso total; a maior parte da partilha fica num objeto de partilha relacionado; a hierarquia de funções é calculada em tempo de execução; as partilhas manuais são removidas quando o proprietário muda, e a partilha gerida via Apex mantém-se; 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; os objetos de detalhe não têm objeto de partilha; o que o objeto de partilha não regista (padrão para toda a organização, hierarquia de funções, 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 os seus contactos, 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 funções, sem regras de partilha nem partilhas manuais; em vez disso, conjuntos de partilha.
• Curso Sharing and Visibility Architect: As 22 formas de partilhar um registo, segundo o Steve, Padrões para toda a organização, propriedade, filas e hierarquia de funções, Relações e partilha nativa, Partilha programática e código seguro, Partilhar com utilizadores externos, Partilha à 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.