

Toda base de datos crece hasta el punto en que buscar deja de ser trivial.
Los campos ayudan, pero cada campo pertenece a un solo objeto y responde a una pregunta prevista de antemano.
Un tag resuelve el caso contrario: una marca transversal que cruza objetos distintos y que se define en el momento en que hace falta.
Es la diferencia entre una estantería fija y una etiqueta adhesiva que se pega donde corresponda.
Una campaña de fin de año toca productos, pedidos, gastos y tickets al mismo tiempo.
Crear un campo nuevo en cada uno de esos objetos para marcarla sería un trabajo desproporcionado.
Con un tag alcanza con definir la etiqueta una sola vez y aplicarla donde corresponda.
Después, un Informe por esa etiqueta reúne en una sola vista todo lo que la campaña movió.
Un campo vive dentro de un objeto y hay que definirlo antes de poder usarlo.
Un tag vive por su cuenta y se relaciona con los registros que lo necesiten.
Por eso un campo sirve para lo estable y una etiqueta para lo circunstancial.
Cuando una etiqueta se vuelve permanente y crítica, suele ser señal de que ya merece un campo propio.
Un Tema se escribe con el signo numeral dentro de una publicación y nace de la conversación.
Un tag es un registro de la base de datos con su código, su categoría y su responsable.
La diferencia práctica es de gobierno: el tema lo crea cualquiera al escribir y la etiqueta se administra.
Los dos sirven, pero para propósitos distintos.
El riesgo de cualquier sistema de etiquetas es la proliferación desordenada.
Sin criterio aparecen tres etiquetas que dicen lo mismo con nombres apenas distintos, y ninguna sirve para filtrar.
Agrupar cada etiqueta en una categoría y darle un código corto mantiene el vocabulario acotado y legible.
Desactivar las que cayeron en desuso, en lugar de borrarlas, conserva la historia sin ensuciar las listas.
Con etiquetas ordenadas, una Vista de lista se filtra por criterios que ningún campo había previsto.
Un Informe agrupado por etiqueta muestra el peso real de cada iniciativa dentro del negocio.
Y un Panel de información deja esa lectura a mano para quien tiene que decidir.
Ese es el punto: la etiqueta no es el fin sino la puerta hacia el análisis.
Dentro de la Plataforma, el tag es un objeto propio de la base de datos, con su Página de registro y su propietario.
El campo EGA Futura Tag guarda el nombre visible, con hasta ochenta caracteres.
Código de Tag guarda una versión corta de hasta cuarenta caracteres, marcada como identificador externo y único sin distinguir mayúsculas.
Esa unicidad es la que impide que convivan dos etiquetas con el mismo código escritas de forma distinta.
Categoría es una lista de selección con dieciocho valores que ordenan el vocabulario por área.
Ahí están Ventas, Marketing, Soporte, Finanzas, Legal, Recursos Humanos, Seguridad y Capacitación, entre otros.
Activo es una casilla obligatoria que permite retirar una etiqueta de circulación conservando el registro.
Descripción admite texto enriquecido y Comentarios suma notas breves para el equipo que administra el vocabulario.
Cada tipo de registro se vincula con las etiquetas mediante un objeto de relación propio.
Hay uno para Producto, uno para Pedido, uno para Orden de compra y uno para Gasto.
Hay otros cinco para Ticket de servicio, Tarea de proyecto, Documento, Artículo de conocimiento y Activo fijo.
Esa estructura es la que hace posible que una misma etiqueta cruce nueve tipos de registro distintos.
La etiqueta se aplica desde la Lista relacionada que aparece dentro del registro.
Desde el registro de la etiqueta, la lista inversa muestra todo lo que lleva esa marca.
Un Informe sobre el objeto de relación permite contar cuántos registros de cada tipo reúne cada etiqueta.
La Plataforma guarda además la fecha en que cada etiqueta fue consultada por última vez, dato que ayuda a detectar las que quedaron en desuso.
Un campo pertenece a un solo objeto y forma parte de su estructura.
Una etiqueta es un registro independiente que se vincula con muchos objetos a la vez.
La regla práctica es simple: lo que se repite siempre merece un campo y lo que cambia con cada iniciativa merece una etiqueta.
Sí, y es justamente el motivo por el que existe.
Una etiqueta llamada Campaña de verano puede marcar productos, pedidos, gastos y tickets al mismo tiempo.
Cada vínculo se guarda en un objeto de relación propio, lo que permite medir por separado cuánto aportó cada tipo de registro.
Desmarcar la casilla Activo la retira de circulación sin perder nada.
Los registros que ya la tenían aplicada conservan su vínculo y siguen apareciendo en los Informes históricos.
Borrarla, en cambio, rompe la lectura de los períodos anteriores.
Es una forma corta y única de nombrar la etiqueta, pensada para integraciones y cargas masivas.
Al estar marcado como identificador externo, permite referirse a la etiqueta sin conocer su identificador interno.
Su unicidad sin distinción de mayúsculas evita duplicados nacidos de una diferencia de escritura.

El objeto es EGAFutura__EGA_Futura_Tag__c y su etiqueta es EGA Futura Tag.
El campo Name es texto de ochenta caracteres y el correlativo propio es EGAFutura__EGA_Futura_ID__c, de tipo Auto Number.
El código corto es EGAFutura__TagCode__c, texto de cuarenta caracteres marcado como External ID y Unique Case Insensitive.
La casilla EGAFutura__IsActive__c es obligatoria, y EGAFutura__Description__c es un área de texto enriquecido de treinta y dos mil caracteres.
EGAFutura__Category__c muestra sus etiquetas en español pero almacena los valores en inglés, y esa diferencia importa al filtrar por API o desde código.
Las equivalencias son Tema de Negocio igual a Business Topic, Proceso igual a Process, Cliente igual a Customer, Proyecto igual a Project y Cumplimiento igual a Compliance.
Siguen Técnico igual a Technical, Marketing, Ventas igual a Sales, Soporte igual a Support, Finanzas igual a Finance, Legal y Recursos Humanos igual a Human Resources.
Cierran Seguridad igual a Security, Capacitación igual a Training, Urgente igual a Urgent, Interno igual a Internal, Externo igual a External y Otro igual a Other.
El vínculo con cada tipo de registro vive en un objeto intermedio, y son nueve en total.
Son EGAFutura__Relacion_Producto_EGA_Futura_Tag__c, EGAFutura__Relacion_Pedido_EGA_Futura_Tag__c, EGAFutura__Relacion_Orden_comp_EGA_Futura_Tag__c y EGAFutura__Relacion_Gasto_EGA_Futura_Tag__c.
Siguen EGAFutura__Relacion_Ticket_ser_EGA_Futura_Tag__c, EGAFutura__Relacion_Tarea_pro_EGA_Futura_Tag__c y EGAFutura__DocumentTag__c.
Cierran EGAFutura__KnowledgeArticleTag__c y EGAFutura__FixedAssetTag__c, que cubren artículos de conocimiento y activos fijos.
El objeto expone Feed e History, así que admite conversaciones y seguimiento de cambios sobre sus campos.
También expone LastViewedDate y LastReferencedDate, campos que permiten ordenar las etiquetas por uso reciente.
Una consulta que cuente registros por etiqueta conviene armarla sobre el objeto de relación y no sobre el tag.
Todos los campos personalizados llevan el prefijo EGAFutura__, propio del paquete gestionado.