Una tabla tiene campos, la misma familia de tipos que acaba de aprender: texto, números, fechas, selecciones, relaciones, archivos. Puede tener vistas y agregaciones guardadas. Puedes exportarlo. Puede relacionar una fila con una persona, una empresa u otra tabla. Los flujos y Workflows pueden leerlo y escribirlo cuando necesite una búsqueda o una simple actualización.

No tiene tipos de registros. No hay Lead versus Contact dentro de una tabla. No lleva la capa CRM que se obtiene en los objetos: notas, tareas pendientes y asignaciones a los usuarios de Frontline. Si se da cuenta de que desea convertir una fila, registrar una llamada en ella o darle un propietario, quería un objeto.

Los permisos son un poco más flexibles, a propósito. El esquema de un objeto es el modelo compartido CRM, por lo que solo los administradores y propietarios le modifican la forma. Una tabla es propiedad de la persona que la creó. Los administradores, el creador y cualquier persona que tenga acceso completo pueden cambiar las columnas. Eso hace que las mesas sean un buen lugar para que un equipo mantenga una lista de trabajo sin abrir un ticket para cambiar el modelo de la empresa.

Utilice una tabla cuando la fila contenga datos de respaldo. Una empresa patrimonial puede mantener una lista de tarifas, una lista de carteras modelo o un conjunto de códigos de custodio. Un equipo de ventas puede conservar los SKU o códigos de campaña. Operaciones puede mantener una lista de ubicaciones de oficinas que casi nunca necesitan que se registre una reunión.

La prueba es la misma de la lección del modelo de datos. ¿Asignarías un propietario, escribirías una nota y volverías a la fila el próximo mes porque la relación cambió? En caso afirmativo, es un objeto. Si solo lo buscas para completar otro registro, es una tabla.

Harrington Family Office hace esto concreto. James es una persona. El family office es una empresa. El mandato es un acuerdo. El cambio de beneficiario es un Boleto. Ninguno de ellos pertenece a una mesa. Las carteras modelo de la empresa sí lo hacen. Cada cartera tiene un nombre, un perfil de riesgo, un mínimo y una tarifa. Los asesores relacionan a James o el acuerdo con "Balanced Tax-Aware", en lugar de escribir la tarifa en un campo de texto en cada contacto. Cuando cambia la tarifa, cambia una fila de la tabla. Cada registro vinculado todavía apunta a la cartera correcta.

Una lista de tarifas puede funcionar de la misma manera: clase de acciones, punto de corte, tasa. Una lista de custodios también puede hacerlo, si cada custodio es solo un código y un nombre. Si un custodio se convierte en una relación real, con personas, tickets y un hilo de correos electrónicos, promueva esa idea a una empresa o a un objeto personalizado. No estire una mesa para convertirla en un segundo CRM.

El movimiento útil es una relación. Un campo en People, Deals o un objeto personalizado puede apuntar a una fila de la tabla. James puede tener una relación de cartera modelo. El trato puede tener lo mismo. Obtiene una etiqueta limpia, un lugar para hacer clic y una lista que mantener.

No copie los valores de la tabla en campos de texto "para que aparezcan en el contacto". Así es como la tarifa sobre James se diferencia de la tarifa sobre la mesa. Relacionar, luego mostrar la relación en la vista. Si necesita un número en la oferta para una fórmula, sáquelo de la fila relacionada o mantenga un campo de moneda única que actualice a propósito. Se separarán dos copias manuscritas.

Las mesas también son un buen insumo para las automatizaciones. Un Workflow puede buscar una tarifa, escribir una fila cuando aparece una nueva clase de acciones o mantener una lista sincronizada con un sistema externo. Como la mesa es plana, la automatización sigue siendo sencilla. No está convirtiendo tipos de registros ni fusionando líneas de tiempo. Estás leyendo una lista.

Lo que no debes hacer es recrear People o Companies como tabla. Pierde deduplicación, sincronización de correo electrónico, enlace automático de la empresa, perfiles de IA y el historial de actividad. Una tabla de "Contactos" es el acceso directo más caro del producto. Utilice el objeto People.

Nombra la tabla según la lista que es. "Carteras modelo". “Lista de tarifas”. "Códigos de custodia". Dale las columnas que miras hacia arriba y detente. Una tabla a la que le crecen un estado, un propietario, una fecha de cierre y una columna de notas está intentando convertirse en un objeto. Escuche eso. Mueva el trabajo antes de que el equipo invente un proceso que la mesa no pueda soportar.

Las vistas todavía ayudan. Una lista de tarifas puede tener una vista por clase de acciones. Una lista de cartera se puede ordenar por riesgo. Las agregaciones pueden sumar mínimos o contar filas. Eso es suficiente. La riqueza debería permanecer en James, la family office y el mandato, donde las actividades y los tipos de registros ya hacen el trabajo.

Si la cosa es una persona, una empresa, un trato, un billete u otro sustantivo con un ciclo de vida, es un objeto. Si la cosa es una lista a la que los objetos deben hacer referencia, es una tabla. Si no está seguro, comience con un campo de selección. Ascienda a una tabla cuando la lista necesite columnas adicionales. Promuévalo a objeto cuando necesite vida propia.

Si lo hace bien, el workspace seguirá siendo legible. People, empresas, ofertas y boletos mantienen las relaciones. Las tablas contienen los datos de referencia. Max, sus Workflows y un nuevo asesor pueden encontrar la tarifa de la misma manera: en la fila de la cartera, no enterrada en una nota sobre James.

A continuación en este curso configuraremos vistas, de modo que los mismos objetos y tablas puedan mostrar una canalización, una lista de trabajo o un tablero filtrado sin cambiar el modelo subyacente.