EGA Futura » Capacitación y Soporte
Una Lista de selección es un campo que no se escribe, se elige.
Al abrirlo aparece un conjunto de valores ya definidos y se marca uno.
Nada de lo que esté fuera de esa lista se puede cargar, y esa limitación es el motivo por el que el campo existe.
Un campo de texto libre parece más cómodo al principio.
El problema aparece al mes siguiente, cuando el mismo estado quedó escrito como pendiente, Pendiente, pend. y en espera.
Para la base de datos esos cuatro son cuatro valores distintos.
Un informe agrupado por ese campo muestra cuatro grupos donde debería haber uno, y el número deja de ser confiable.
La Lista de selección resuelve eso de raíz, porque solo existe una forma de decir cada cosa.
Hay dos variantes y la diferencia es cuántos valores admite cada una.
La de selección única acepta un solo valor por registro, y es la que conviene cuando las opciones se excluyen entre sí.
El estado de un pedido es el caso típico, porque un pedido no puede estar entregado y cancelado a la vez.
La de selección múltiple acepta varios valores al mismo tiempo.
Sirve para atributos que se acumulan, como los idiomas que habla un contacto.
Conviene usarla con cuidado, porque los campos de selección múltiple son más incómodos de filtrar y de agrupar que los de valor único.
Los valores los define el administrador desde la configuración del campo.
No es una decisión que cada usuario tome sobre la marcha, y eso es deliberado.
Si cualquiera pudiera agregar opciones, en pocas semanas la lista tendría el mismo desorden que un campo de texto libre.
Se nota en tres lugares.
En la Página de registro aparece como un desplegable en lugar de una caja de texto vacía.
En el Filtro de una Vista de lista los valores posibles ya vienen listados, sin tener que escribirlos.
En un Kanban, un campo de selección única es lo que define las columnas del tablero.
Sacar un valor de la lista no borra lo que ya se cargó con él.
Los registros viejos conservan el valor anterior, y quedan datos que ya no figuran entre las opciones disponibles.
Por eso conviene pensar la lista antes de ponerla en uso y no ir corrigiéndola sobre la marcha.
La Plataforma EGA Futura usa Listas de selección en casi todos sus objetos.
Los campos de estado, de etapa, de tipo y de prioridad suelen ser Listas de selección, porque son justamente los que necesitan un vocabulario cerrado.
Un campo de este tipo no sirve solo para cargar el dato.
Es lo que permite agrupar registros en un informe, armar un tablero Kanban por etapas y filtrar una Vista de lista sin errores de tipeo.
Un campo de texto libre no habilita nada de eso con la misma confiabilidad.
Un equipo carga el estado de sus pedidos en un campo de texto libre durante seis meses.
Al pedir un informe por estado aparecen veintitrés valores distintos para lo que en realidad son cinco situaciones.
Pasar ese campo a Lista de selección arregla el futuro, pero los seis meses viejos hay que normalizarlos a mano.
Conviene cuando las opciones son estables y se pueden enumerar.
No conviene cuando los valores posibles son muchísimos, cambian seguido o son nombres de otros registros.
Para ese último caso el campo adecuado es un Campo de búsqueda relacionado y no una Lista de selección.
En que el valor se elige de un conjunto cerrado en lugar de escribirse.
Esa diferencia es la que hace confiables los informes agrupados por ese campo.
Solo si el campo es de selección múltiple.
El de selección única admite un valor por registro y es el más común.
El administrador, desde la configuración del campo.
No es algo que se pueda resolver mientras se carga un registro.
Conservan el valor con el que se cargaron.
Por eso conviene revisarlos antes de sacar una opción que estuvo mucho tiempo en uso.
Tres preguntas ordenan casi todo el diseño de una Lista de selección.
El orden en que se cargan las opciones es el orden en que las va a ver todo el mundo.
Conviene ponerlas siguiendo el orden real del proceso y no en orden alfabético, así el desplegable acompaña el trabajo en lugar de estorbarlo.
Renombrar un valor y quitar un valor no son la misma operación.
Un valor quitado sigue existiendo en los registros viejos aunque ya no aparezca entre las opciones.
Antes de sacar una opción conviene contar cuántos registros la usan y decidir a qué valor se migran.
Cuando los valores no son evidentes por su nombre, la Ayuda a nivel de campo evita que cada persona interprete distinto la misma opción.
Es más barato explicar el criterio una vez ahí que corregir los datos después.