Cómo construir una intranet corporativa con Drupal: permisos, contenidos colaborativos y flujos de trabajo

Las intranets corporativas llevan décadas entre nosotros y no van a desaparecer. En organizaciones de más de 50 empleados siguen siendo el eje de la comunicación interna, el sitio donde confluyen documentos, noticias, procesos y esa información que todo el mundo necesita pero nadie sabe dónde está. Según datos de Prescient & Strategic Intelligence, el mercado global de plataformas de intranet alcanzará los 45.000 millones de dólares en 2028, impulsado por la necesidad de centralizar información y ofrecer experiencias digitales coherentes a equipos distribuidos.

Drupal ocupa un lugar particular en este mapa. No es la opción que aparece primero en la conversación --SharePoint y Confluence dominan esa parte-- pero después de 12 años construyendo plataformas corporativas, puedo decir que su flexibilidad como framework de gestión de contenidos, su sistema granular de permisos y su arquitectura modular lo convierten en una alternativa técnicamente superior cuando la organización necesita control total sin depender de licencias por usuario. Es como elegir entre una casa prefabricada y construir sobre cimientos propios: ambas opciones son válidas, pero las posibilidades de la segunda no tienen techo.

Esta guía recorre cómo diseñar y construir una intranet corporativa con Drupal 10/11: desde la arquitectura de contenidos hasta los flujos de aprobación, pasando por la integración con directorios corporativos y las métricas de adopción.

Por qué Drupal para intranets frente a SharePoint y Confluence

SharePoint domina el mercado empresarial por su integración nativa con Microsoft 365. Confluence brilla en equipos técnicos por su enfoque en documentación colaborativa. Drupal entra en juego cuando los requisitos desbordan lo que estas plataformas ofrecen de serie.

Control sobre la experiencia de usuario. SharePoint impone una estructura visual que se personaliza dentro de márgenes predefinidos. Con Drupal, el frontend es territorio libre: puedes construir una experiencia que respire la cultura visual de la organización sin que ninguna plantilla te corte las alas.

Modelo de costes predecible. SharePoint Online cobra por usuario (entre 5 y 35 USD/mes). Haz la cuenta para una organización de 2.000 empleados: entre 120.000 y 840.000 USD anuales solo en licencias. Drupal es open source. El coste se concentra en desarrollo, hosting y mantenimiento, y a largo plazo la diferencia es abismal.

Flexibilidad en la arquitectura de contenidos. Aquí es donde Drupal se separa del resto. Puedes definir tipos de contenido, campos personalizados y relaciones entre entidades con una granularidad que ni SharePoint ni Confluence alcanzan sin desarrollo adicional. Una intranet típica necesita noticias internas, documentos con versionado, directorio de empleados, FAQs departamentales, calendarios y espacios de proyecto. En Drupal, cada elemento es un tipo de contenido con su propia estructura, permisos y flujo editorial. Cada pieza encaja en su lugar.

Integración abierta. Drupal se conecta con prácticamente cualquier sistema mediante APIs REST, JSON:API o módulos de integración. SharePoint funciona bien dentro del ecosistema Microsoft, pero empieza a chirriar cuando necesitas integrar sistemas externos. Si la organización utiliza Google Workspace, Slack o ERPs como SAP, Drupal ofrece una base de integración más neutral.

Dicho esto, la decisión no siempre cae del lado de Drupal. Si la organización ya tiene Microsoft 365 desplegado y las necesidades son estándar, SharePoint puede ser el camino más corto. Drupal gana cuando los requisitos incluyen flujos de trabajo complejos, personalización avanzada o integración con sistemas heterogéneos.

Arquitectura de contenidos: los tipos de contenido que toda intranet necesita

El error más repetido al arrancar una intranet con Drupal es lanzarse a instalar módulos antes de sentarse a pensar en los contenidos. Es como empezar a levantar tabiques sin tener planos. Antes de tocar una línea de configuración, hay que mapear qué información necesitan los empleados en su día a día.

Noticias internas. Campos para título, cuerpo WYSIWYG, imagen destacada, categoría (empresa, departamento, RRHH, TI), fecha de publicación y fecha de expiración. Ese último campo lo olvidan muchos proyectos, y es un fallo que pasa factura: las noticias obsoletas erosionan la confianza en la plataforma más rápido que cualquier bug. El módulo Scheduler programa la despublicación automática.

Documentos y políticas. Archivo adjunto (PDF, DOCX), versión, fecha de vigencia, departamento propietario y estado de revisión. El módulo Media Library gestiona los archivos y el sistema de revisiones de Drupal mantiene el historial de cambios.

Directorio de empleados. Hay dos caminos: implementarlo como tipo de contenido propio o como perfiles de usuario extendidos. La segunda opción resulta más elegante porque vincula directamente el perfil con la cuenta, aunque requiere más configuración. Campos típicos: foto, nombre completo, cargo, departamento, ubicación, teléfono, email, reporte directo. Views permite crear vistas filtradas por departamento, ubicación o cargo, y el módulo Facets añade filtros interactivos para navegar el directorio de forma intuitiva.

FAQs y base de conocimiento. Pregunta y respuesta categorizadas por tema. Search API con Solr o Elasticsearch potencia las búsquedas. Un sistema de valoración identifica qué contenidos están funcionando de verdad.

Eventos y calendario. Fecha de inicio, fin, ubicación, organizador y capacidad. FullCalendar View visualiza los eventos en formato calendario.

Espacios de equipo o proyecto. Aquí entra el módulo Group, que es una de las piezas más potentes del ecosistema. Cada espacio agrupa contenidos, miembros y permisos de forma independiente. Marketing tiene su espacio con sus documentos y noticias; TI tiene el suyo. El administrador del grupo gestiona quién entra y qué puede hacer. Son como plantas de un mismo edificio, cada una con su llave.

Sistema de permisos y roles: la granularidad que hace viable una intranet

La gestión de permisos es el pilar sobre el que se sostiene toda la estructura. Y es donde Drupal demuestra su superioridad técnica de forma más evidente.

Roles globales. Drupal permite crear roles ilimitados con permisos granulares. Un diseño típico incluye: Empleado (lectura + contenido básico), Editor Departamental (noticias y documentos de su área), Responsable de RRHH (políticas y directorio), Administrador de TI y Super Administrador.

Permisos por grupo con Group. Cada grupo (departamento, proyecto, comité) tiene sus propios roles internos: miembro, editor, administrador. Un empleado puede ser miembro básico de Marketing pero administrador del Comité de Sostenibilidad. Esta flexibilidad refleja la realidad organizacional, que rara vez sigue líneas rectas.

Control de acceso a campos con Field Permissions. El campo "salario" en el perfil de empleado solo es visible para RRHH y el propio empleado; la "evaluación de desempeño" solo para el responsable directo y RRHH. Este nivel de detalle marca la diferencia entre una intranet que genera confianza y una que genera problemas.

Permisos basados en taxonomía con Taxonomy Access Control. Si una noticia está etiquetada como "Confidencial - Dirección", solo los usuarios con el rol adecuado pueden verla.

Recomendaciones prácticas para la gestión de permisos:

• Documenta la matriz de permisos en una hoja de cálculo antes de configurar nada en Drupal. Cada fila es un tipo de contenido y acción, cada columna un rol.
• Aplica el principio de menor privilegio: cada rol tiene exactamente los permisos que necesita y nada más.
• Revisa los permisos trimestralmente. Las organizaciones cambian, la gente rota de departamento, y los permisos tienden a acumularse si nadie los audita. He visto intranets donde el becario de hace tres años seguía teniendo permisos de editor.
• Implementa un proceso formal para solicitar cambios de permisos, idealmente a través de un formulario Webform en la propia intranet que alimente un flujo de aprobación.

Módulos que forman los cimientos de una intranet Drupal profesional

Group. Transforma Drupal en una plataforma de colaboración departamental con espacios aislados. La versión para Drupal 10/11 soporta subgrupos para modelar jerarquías complejas. Si la intranet fuera un edificio, Group sería el sistema de puertas y cerraduras.

Content Moderation (core). Define estados de publicación personalizados (borrador, en revisión, aprobado, publicado, archivado) y transiciones entre ellos. Es la base sobre la que se levantan los flujos de aprobación.

ECA (Event-Condition-Action). Automatiza acciones basadas en eventos: cuando una noticia pasa a "en revisión", envía email al editor. ECA es el sucesor de Rules para Drupal 10/11, con interfaz visual incluida.

Search API + Solr/Elasticsearch. Búsqueda facetada, autocompletado y resultados ponderados. Según McKinsey, los empleados dedican el 19% de su jornada a buscar información interna. Una buena búsqueda tiene retorno directo en productividad, y no hablo de retorno teórico.

Message + Message Notify. Sistema de notificaciones personalizado donde cada usuario elige qué recibir y por qué canal.

LDAP / SimpleSAML. Integración con directorio corporativo y single sign-on.

Webform. Formularios internos: solicitudes de vacaciones, reserva de salas, encuestas. Lógica condicional, envío de emails y almacenamiento de resultados.

Diseño UX para intranets: principios que determinan la adopción

El 40% de los proyectos de intranet fracasan por baja adopción, según Interact Intranet. Y la causa principal casi nunca es técnica. Es de diseño.

Dashboard personalizado como página de inicio. Cada empleado debe ver la información relevante para su rol: noticias de su área, documentos pendientes, eventos próximos y accesos directos a herramientas frecuentes. Layout Builder o Views contextuales permiten esta personalización sin desarrollo a medida.

Búsqueda prominente. La barra de búsqueda debe ser el elemento más visible de la página. Los usuarios de intranet saben lo que buscan y quieren encontrarlo rápido. No escondas la búsqueda detrás de un icono de lupa. Este error lo he visto decenas de veces y siempre tiene el mismo resultado: nadie usa el buscador.

Navegación por audiencia, no por organigrama. Una estructura orientada a tareas ("Necesito...", "Quiero saber...", "Tengo que solicitar...") reduce la fricción frente a la navegación departamental clásica. Los empleados piensan en lo que necesitan hacer, no en qué departamento gestiona esa tarea.

Mobile-first. En sectores con personal no vinculado a escritorio (retail, logística, sanidad), el acceso móvil no es un complemento: es el acceso principal. Las funcionalidades clave deben funcionar sin fricciones en pantallas pequeñas.

Integración con Active Directory, LDAP y Single Sign-On

Los empleados deben acceder con las mismas credenciales que usan para su email. Punto. Si les pides otra contraseña, ya has perdido parte de la batalla de la adopción. Y el directorio de usuarios debe sincronizarse con el directorio corporativo.

LDAP. El módulo LDAP autentifica contra Active Directory, sincroniza atributos (nombre, departamento, cargo) y asigna roles de Drupal basados en grupos de AD. La configuración incluye servidor LDAP, Base DN, mapeo de atributos (sAMAccountName a nombre de usuario, mail a email) y mapeo de grupos.

La sincronización puede ser al login (lazy provisioning) o por cron. El lazy provisioning es más sencillo pero los usuarios no existen en Drupal hasta su primer login. La sincronización por cron resuelve esto a costa de gestionar el volumen: en organizaciones de 10.000 empleados puede tardar varios minutos.

SSO con SAML. SimpleSAMLphp Authentication conecta Drupal con Azure AD, Okta, Google Workspace o ADFS. El flujo es transparente para el usuario: accede a la intranet, se le redirige al proveedor de identidad donde ya está autenticado, y vuelve con sesión iniciada. Cero contraseñas adicionales. Funciona y la gente ni se entera de la fontanería que hay debajo.

La configuración requiere intercambiar metadatos entre el proveedor de identidad (IdP) y Drupal (SP), configurar certificados de firma y definir el mapeo de atributos. Es un proceso técnico pero bien documentado, y la mayoría de proveedores de identidad corporativa soportan SAML 2.0.

OAuth 2.0. El módulo OpenID Connect permite autenticación mediante OAuth 2.0 como alternativa más ligera a SAML, aunque con menos control sobre los atributos sincronizados. Es la opción recomendada para organizaciones que usan Google Workspace como proveedor de identidad principal.

Flujos de trabajo y aprobación de contenidos

El contenido de una intranet representa la voz oficial de la organización. Un error puede tener consecuencias reales --desde confusión interna hasta problemas legales--. Content Moderation permite definir estados y transiciones con precisión quirúrgica. Un flujo típico para noticias: Borrador, Pendiente de revisión, Publicado, Archivado. Cada transición se limita a roles específicos.

Ahora bien, no todo el contenido necesita el mismo nivel de supervisión. Las noticias corporativas pueden requerir aprobación de Comunicación; los documentos de política necesitan visto bueno de Legal y del director del departamento; los posts en espacios de equipo pueden publicarse directamente. Drupal permite asignar diferentes flujos de trabajo a diferentes tipos de contenido, y eso evita que el control editorial se convierta en un cuello de botella que paralice la plataforma.

Cada cambio de estado debe generar una notificación al responsable del siguiente paso. Si el editor departamental tiene 15 noticias pendientes de revisión y no lo sabe, el flujo se estanca. ECA permite configurar estas notificaciones automáticas por email, mensaje en la plataforma o ambos. El sistema de revisiones mantiene un historial completo de quién editó qué, cuándo y qué cambió --un requisito para auditoría y cumplimiento normativo en sectores regulados--.

Notificaciones y mecanismos para impulsar el uso diario

La sobrecarga de notificaciones mata la adopción. El objetivo es notificar lo relevante a quien le importa, ni más ni menos. Message Subscribe permite que los usuarios se suscriban a contenidos o grupos específicos. Un digest diario o semanal reduce el volumen de email. Web Push Notifications cubre las comunicaciones urgentes.

Si la organización ya usa Slack o Teams, la intranet puede publicar automáticamente en canales específicos mediante webhooks. No compitas con las herramientas que ya usan; intégrate con ellas.

En cuanto a gamificación, un sistema de puntos y badges incentiva contribuir contenido (publicar, comentar, completar el perfil). El reconocimiento entre pares tipo "kudos" permite que los empleados reconozcan públicamente a compañeros. Las métricas de participación por departamento generan responsabilidad colectiva sin señalar individuos. Funciona mejor de lo que parece sobre el papel.

Métricas de adopción: cómo saber si la intranet funciona

Sin métricas, estás construyendo a ciegas. Las métricas cuantitativas clave son: usuarios activos (DAU/WAU/MAU, con un ratio DAU/MAU por encima de 0,3 como referencia saludable), tasa de login sobre censo total, contenidos creados por departamento, y tasa de éxito de búsqueda (búsquedas que resultan en un clic; por debajo del 60% indica problemas serios en la arquitectura de información).

Las métricas cualitativas incluyen encuestas trimestrales NPS, análisis de búsquedas sin resultados y feedback directo mediante mecanismos de valoración en cada página. Matomo Analytics o Google Analytics proporcionan la base cuantitativa; Search API Logs registra las consultas de búsqueda.

Hoja de ruta para los primeros seis meses de una intranet Drupal

Un proyecto típico dura 4-8 meses dependiendo de la complejidad. Esta es una hoja de ruta realista basada en proyectos que hemos ejecutado:

Mes 1-2: Descubrimiento y arquitectura. Entrevistas con stakeholders de cada departamento, mapeo de necesidades de contenido, definición de la arquitectura de información, diseño de la matriz de permisos y selección de módulos. Entregable: documento de arquitectura técnica y wireframes de baja fidelidad. Esta fase parece lenta pero ahorra meses de retrabajo.

Mes 3-4: Desarrollo del MVP. Implementación de los tipos de contenido principales (noticias, documentos, directorio), configuración de permisos y roles, integración con AD/LDAP, desarrollo del tema frontend y configuración del buscador. Entregable: entorno de staging con contenido de prueba.

Mes 5: Testing y piloto. Pruebas con un grupo de 20-50 usuarios de diferentes departamentos. Recopilación de feedback, ajustes de UX y corrección de bugs. Formación a los editores departamentales. Entregable: plataforma lista para producción.

Mes 6: Lanzamiento y adopción. Despliegue en producción, campaña de comunicación interna, sesiones de formación por departamento y monitorización activa de las métricas de adopción durante las primeras semanas.

Si tu organización está evaluando plataformas para su intranet corporativa o necesita apoyo técnico para un proyecto con Drupal, puedes consultar con nuestro equipo en Tangram Consulting para analizar juntos la arquitectura que mejor se adapte a vuestras necesidades.

La intranet se construye dos veces: al lanzarla y al usarla

Después de participar en proyectos de intranet durante más de una década, el patrón se repite con una claridad casi molesta: las intranets que sobreviven tienen un propietario interno comprometido, un plan de contenidos activo y un ciclo de mejora basado en datos reales de uso. Las que mueren tienen tecnología impecable y a nadie mirando los números.

La tecnología facilita. No diferencia. La diferencia la marca la gobernanza: quién decide qué se publica, quién mantiene el contenido actualizado, quién analiza las métricas y quién toma decisiones basadas en ellas. Drupal ofrece la base técnica más flexible para construir una intranet que crezca con la organización, pero esa flexibilidad requiere un equipo competente y una estrategia de contenidos sostenida. La herramienta sin el equipo es solo software instalado.

La intranet perfecta no existe al lanzamiento. Existe después de seis meses de iteración, cuando los datos de uso han revelado qué funciona, qué sobra y qué falta. Drupal, con su arquitectura modular, permite esa iteración continua: añadir un tipo de contenido, ajustar un flujo de aprobación o integrar una nueva herramienta son operaciones incrementales que no comprometen la estabilidad del conjunto. Como una buena construcción, los cimientos aguantan lo que le eches encima.