Los roles controlan el acceso a registros completos, pero ¿qué pasa cuando necesitas ser más granular? Field Security permite ocultar o restringir campos específicos como salarios, números de identificación o márgenes confidenciales.
Objetivos de aprendizaje
- Entender qué es Field Security y cuándo usarlo
- Configurar campos seguros y Field Security Profiles
- Asignar profiles a usuarios y equipos
- Conocer las limitaciones e impacto en rendimiento
El problema que resuelve Field Security
Imagina este escenario: tienes una entidad de Empleado en tu sistema. Los gerentes necesitan ver y editar información de sus subordinados: nombre, puesto, departamento, fecha de inicio. Pero hay un campo que solo RRHH debería ver: el salario.
Con los roles de seguridad tradicionales no puedes resolver esto limpiamente. Si das Read en la entidad Empleado, eso incluye todos los campos. Podrías crear una entidad separada solo para salarios, pero eso añade complejidad innecesaria y fragmenta los datos.
Field Security resuelve este problema permitiéndote controlar el acceso a campos individuales, independientemente del acceso al registro completo. Un gerente puede ver el registro del empleado pero no el campo de salario. Alguien de RRHH ve el mismo registro incluyendo el salario.
Cómo funciona Field Security
Field Security es un sistema de tres componentes que trabajan juntos:
1. Campos habilitados para seguridad
No todos los campos pueden tener seguridad a nivel de campo. Primero, tienes que habilitar la opción "Field Security" en la definición del campo específico. Esto es una configuración de metadatos que no puedes cambiar después para campos del sistema (aunque sí para campos personalizados).
Cuando habilitas la seguridad en un campo, por defecto ese campo queda "oculto" para todos los usuarios que no tengan acceso explícito a través de un profile.
2. Field Security Profiles
Un Field Security Profile es como un "perfil de acceso a campos". Define, para cada campo con seguridad habilitada, qué permisos tienen los miembros del profile:
- Read: Puede ver el valor del campo
- Create: Puede establecer el valor al crear un registro
- Update: Puede modificar el valor en registros existentes
Estos tres permisos son independientes. Podrías tener un profile que permita Read pero no Update (ver pero no cambiar) o incluso Create pero no Read (útil para campos que solo se llenan una vez y luego no se muestran).
3. Asignación a usuarios/equipos
Finalmente, asignas usuarios o equipos al Field Security Profile. Los miembros del profile obtienen los permisos que el profile define para cada campo seguro.
Un usuario puede estar en múltiples profiles, y los permisos son acumulativos. Si el Profile A le da Read en un campo y el Profile B le da Update, el usuario tiene Read + Update.
Qué ve un usuario sin acceso
Cuando alguien no tiene acceso a un campo con seguridad habilitada, la experiencia depende del contexto:
- En formularios, el campo aparece pero muestra asteriscos (******) o un mensaje de "no tiene acceso"
- En vistas, la columna puede aparecer vacía o con asteriscos
- En exports, el campo no se incluye o muestra valor vacío
- En API/código, el campo simplemente no está presente en los resultados
Esto es importante: el usuario sabe que el campo existe, pero no puede ver su valor. Si por razones de experiencia de usuario no quieres que ni siquiera vean el campo en el formulario, tendrías que ocultarlo con lógica de formulario además de la seguridad.
La excepción: System Administrator
Hay algo crítico que ya mencionamos en el Módulo 2 pero vale la pena repetir: el rol System Administrator ignora Field Security. Un usuario con este rol puede ver todos los campos, tengan o no seguridad habilitada, esté o no en un Field Security Profile.
Esto es por diseño: un administrador del sistema necesita poder diagnosticar problemas sin restricciones. Pero significa que si tienes datos verdaderamente ultra-sensibles (quizás datos médicos o información de pagos con regulaciones estrictas), necesitas ser cuidadoso sobre quién tiene System Administrator.
Impacto en rendimiento
Field Security tiene un costo. Cada vez que alguien accede a un registro que tiene campos con seguridad habilitada, el sistema debe verificar los permisos del usuario para cada uno de esos campos. Esto añade procesamiento a cada consulta.
En organizaciones pequeñas con pocos campos seguros, el impacto es imperceptible. Pero he visto casos donde alguien habilitó seguridad en 30 campos y creó 15 profiles con cientos de usuarios, y el rendimiento de las vistas se degradó notablemente.
Mejores prácticas para evitar problemas:
- Usa Field Security solo en campos que realmente lo necesitan, no preventivamente
- Evita habilitar seguridad en campos que se muestran frecuentemente en vistas principales
- Minimiza el número de profiles - agrupa usuarios con necesidades similares
- Monitorea el rendimiento después de implementar, especialmente en vistas con muchos registros
Casos de uso típicos
Algunos escenarios donde Field Security es la herramienta correcta:
Información de compensación: El campo de salario en empleados solo visible para RRHH y el gerente directo.
Márgenes de beneficio: En oportunidades, el margen porcentual solo visible para gerentes de ventas y finanzas, no para los vendedores que ven el precio de venta.
Datos de identificación: Números de seguro social, pasaporte o identificación fiscal solo visibles para departamentos específicos que los necesitan por razones legales.
Información médica: En casos de soporte o servicios que manejan información de salud, los campos sensibles restringidos según HIPAA u otras regulaciones.
Puntos clave
- Field Security controla acceso a campos individuales, no registros completos
- Requiere tres componentes: campo habilitado + profile + asignación
- Tres permisos independientes: Read, Update, Create
- System Administrator ignora Field Security - siempre ve todo
- Tiene impacto en rendimiento - usar con moderación
- Usuarios sin acceso ven asteriscos o campos vacíos