Defina seu modelo de dados na Spryx

Um bom modelo de dados representa sua operação sem duplicar informações nem criar estruturas mais complexas do que o necessário. Depois de entender as peças da Spryx, use este guia para escolher qual delas resolve cada necessidade.

Você não precisa desenhar o modelo perfeito antes de começar. Estruture primeiro o que já está claro e evolua quando o processo exigir novos dados ou relações.

Escolha pela função da informação

• Use um atributo para guardar um valor que descreve um Record existente.
• Use um relacionamento para conectar Records de Objects diferentes.
• Use uma View para filtrar, ordenar ou apresentar os mesmos dados de outra forma.
• Use uma Lista quando Records participam de um processo que possui dados próprios.
• Use um Object quando a informação tem identidade, cadastro e relações próprias.

Quando houver dúvida, comece pela estrutura mais simples que preserva o significado dos dados.

Use um atributo para descrever algo que já existe

Crie um atributo quando um único valor descreve o Record em qualquer contexto. Segmento de uma Empresa, Valor de um Deal e Data prevista de um Projeto são exemplos.

Escolha um tipo coerente com o dado. Para valores que precisam ser filtrados de maneira consistente, prefira uma seleção com opções definidas em vez de texto livre.

Use um relacionamento para conectar Records

Se a informação já existe como outro Record, conecte os dois em vez de copiar seu nome para um campo de texto. Um Deal pode se relacionar com uma Empresa; um Ticket pode se relacionar com um Contact.

O relacionamento mantém as duas pontas conectadas e permite navegar entre os Records. Antes de criá-lo, defina também quantos Records podem existir de cada lado.

Use uma View para mudar a perspectiva

Uma View não cria Records nem guarda uma nova participação. Ela define como os dados existentes aparecem por meio de campos visíveis, filtros, ordenação e layout.

Use uma View quando a pergunta puder ser respondida consultando os valores que já existem. Alguns exemplos:

• Deals com previsão de fechamento neste mês;
• projetos sob responsabilidade da pessoa conectada;
• empresas de um segmento específico;
• entradas de uma Lista agrupadas por etapa.

Use uma Lista para acompanhar uma participação

Use uma Lista quando o time escolhe um conjunto de Records para um processo e precisa guardar informações que só existem naquele contexto.

Em uma implantação de clientes, por exemplo, a Empresa continua sendo o Record original. Etapa da implantação, data de início e especialista responsável podem pertencer à entrada em uma Lista chamada Implantação de clientes.

Uma Lista também pode ter diferentes Views. A Lista define quais Records participam e quais dados pertencem ao processo; a View define apenas como essas entradas aparecem.

Use um Object para uma entidade própria

Crie um Custom Object quando o que você acompanha precisa ter vários Records, atributos próprios e relacionamentos com outras partes da operação.

Um Contrato, por exemplo, pode ter número, valor, início, vencimento e um relacionamento com a Empresa. Como uma Empresa pode ter vários contratos, guardar tudo em atributos da Empresa limitaria o histórico e misturaria entidades diferentes.

Antes de criar, confira se um Object de sistema ou um modelo do Catálogo de Objects já representa essa entidade.

Decida entre View e Lista

Essa é a escolha que mais costuma gerar dúvida:

• Use uma View quando os Records podem entrar e sair do resultado por regras baseadas nos dados existentes.
• Use uma Lista quando a participação é escolhida para um processo e precisa ter atributos próprios.

Por exemplo, “todos os Deals acima de R$ 50 mil” pode ser uma View filtrada. Já “Deals escolhidos para a revisão trimestral”, com avaliação e observações específicas da revisão, deve ser uma Lista.

Aplique o modelo a situações reais

• Guardar o segmento de cada Empresa → atributo de seleção. É uma característica da Empresa.
• Ligar um Deal à Empresa compradora → relacionamento. Os dois lados são Records com identidade própria.
• Ver Deals que fecham neste mês → View. O conjunto é obtido com um filtro sobre dados existentes.
• Acompanhar clientes em implantação → Lista. A participação tem etapa e dados próprios do processo.
• Cadastrar vários contratos por Empresa → Custom Object. Cada contrato tem identidade, atributos e relação próprios.

Evite erros comuns

• Não crie um Object para guardar apenas um valor que poderia ser um atributo.
• Não escreva o nome de outro Record em texto quando a informação precisa ser um relacionamento.
• Não crie uma Lista quando uma View filtrada já mantém o conjunto atualizado.
• Não repita o mesmo atributo em várias Listas se ele descreve o Record em todos os contextos; mova-o para o Object.
• Não duplique Objects para cada equipe quando todos trabalham com as mesmas entidades.

Use este caminho de decisão

1. A informação precisa de cadastro, vários atributos e relações próprias? Crie um Object.
2. Ela conecta dois Records existentes? Crie um relacionamento.
3. Ela é apenas um valor que descreve um Record? Crie um atributo.
4. Os Records participam de um processo com dados próprios? Crie uma Lista.
5. Você só precisa filtrar, ordenar ou apresentar os mesmos dados? Crie uma View.

A seguir

Com o modelo de dados concluído, veja como Notas preservam contexto e como Tarefas organizam os próximos passos da equipe.