Cómo Crear un Portal de Empleo Corporativo con Gestión de Candidaturas y Filtros Avanzados en Drupal

Llevo doce años seleccionando perfiles técnicos y todavía recuerdo el viernes en que perdí el rastro de una candidata buenísima para un puesto de DevOps. Su CV se hundió en un hilo de correo con catorce respuestas, mi Excel de seguimiento se había guardado en la carpeta equivocada y el portal genérico que pagábamos cada mes le había mandado un automático en inglés cuando ella había escrito en castellano. La llamé el lunes para disculparme y me dijo que ya había firmado en otro sitio. Esa semana le propuse a Dirección montar nuestro portal en el dominio de la empresa, y arrancamos con un partner técnico que conocía Drupal a fondo. Lo que sigue es el mapa que hubiera querido tener antes de empezar.

Arquitectura de Contenidos: el Andamiaje que Sostiene Todo lo Demás

Antes de tocar una sola plantilla, conviene sentarse con una hoja en blanco y dibujar qué entidades vas a manejar. Cuando hablo con responsables de selección que han heredado portales caóticos, casi siempre el problema viene de aquí: alguien creó una "ficha de oferta" con quince campos sueltos y nadie pensó en cómo se relacionaba con los candidatos. En Drupal este paso se llama definir los tipos de contenido, y es donde merece la pena invertir tiempo.

El tipo principal es Oferta de Empleo, y desde mi experiencia los campos imprescindibles son: título del puesto, descripción en texto enriquecido, departamento como taxonomía, ubicación, modalidad (presencial, híbrido o remoto), tipo de contrato, experiencia requerida, fecha de publicación, fecha de cierre, estado interno y rango salarial. Lo del rango salarial mete ruido al principio (siempre hay alguien de finanzas que se opone), pero los candidatos lo agradecen y filtra mucho la pila de inscripciones.

El segundo tipo es Candidatura, y aquí está la magia: en lugar de tener los datos del candidato pegados en un formulario, cada inscripción se convierte en una entidad propia que apunta a la oferta. Contiene nombre, email, teléfono, CV adjunto, carta de motivación, estado en el pipeline (nueva, en revisión, entrevista, descartada, contratada) y un campo de notas internas. Esas notas internas son oro: ahí va el "muy buen feeling en la primera llamada" o el "pretensiones por encima de banda" que luego te ayuda a no repetir errores.

Un detalle de RGPD que conviene blindar desde el día uno: las candidaturas solo deben ser visibles para los roles de RR.HH. y Administración. Drupal lo resuelve con permisos por rol más un módulo como Content Access o Node Access. Si lo dejas para después, te tocará revisar nodo por nodo y es un dolor.

Configurar Vistas para que el Listado Público Tenga Sentido

El módulo Views es el corazón de cualquier portal en Drupal, y para el listado público de ofertas marca la diferencia entre una página que invita a inscribirse y una lista plana que el candidato cierra en diez segundos. Con Views se construye una página que recoge los nodos de Oferta de Empleo y los presenta con el orden y los filtros que decidas.

Los filtros expuestos son los que el visitante manipula desde la propia página: departamento, ubicación, modalidad y tipo de contrato funcionan en la mayoría de empresas. Aparecen como un formulario encima del listado y se configuran con un par de clics. Yo pediría que el filtro de ubicación admita selección múltiple, porque mucha gente busca en dos ciudades a la vez y se frustra si solo puede marcar una.

Los filtros internos son los que tú no enseñas pero aplicas siempre. Por ejemplo: que la vista solo muestre ofertas con estado "publicada" y cuya fecha de cierre sea posterior a hoy. Así las vacantes caducadas desaparecen solas el día que toca, sin que nadie tenga que acordarse de despublicarlas un domingo por la noche.

Para la búsqueda libre por palabras conviene sumar Search API y Facets. Search API indexa el contenido de las ofertas (en la base de datos de Drupal o, si manejas volumen alto, en Apache Solr) y Facets genera esas etiquetas laterales con contador del tipo "Tecnología (12)" o "Marketing (4)" que tan bien funcionan. Cuando un candidato ve los números, entiende dónde hay oportunidad real y donde no.

Webform y el Formulario de Candidatura: el Momento de la Verdad

El formulario es donde se decide casi todo. Tengo medido que cada campo de más reduce la tasa de envío entre un cinco y un ocho por ciento, así que la regla es pedir solo lo necesario para una primera criba. Lo demás se resuelve en la entrevista.

En Drupal la solución más cómoda es Webform. Se conecta al tipo de nodo Oferta de Empleo mediante el submódulo Webform Node, o colocando el bloque del formulario dentro de la plantilla. El formulario base que uso incluye nombre completo, email con validación, teléfono, adjunto del CV (limitado a PDF y DOC, máximo cinco megas), carta de motivación opcional, un campo oculto que guarda el ID de la oferta y la casilla de consentimiento RGPD con enlace a la política de privacidad. Punto.

Cuando el candidato envía el formulario, el handler de Webform crea un nodo de Candidatura con esos datos y avisa por email al responsable de selección asignado. Conviene también añadir una validación que detecte si ese email ya se ha inscrito a la misma oferta, y en ese caso devolver un mensaje amable del tipo "ya tenemos tu candidatura, te avisamos cuando avancemos" en lugar de crear un duplicado que luego ensucia el panel.

Panel Interno: el Sitio donde RR.HH. Trabaja de Verdad

Aquí es donde se gana o se pierde la batalla del día a día. Si el panel es un infierno, el equipo acaba volviendo al Excel y el portal se convierte en un escaparate vacío de gestión real. Views también construye esta parte, visible solo para el rol Recursos Humanos.

La vista de administración muestra las candidaturas agrupadas por oferta, con columnas para nombre, email, fecha y estado. Desde ahí, quien selecciona puede filtrar por oferta o por estado, cambiar el estado de varias candidaturas a la vez con Views Bulk Operations (acciones tipo "mover a entrevistas" o "descartar"), abrir el perfil completo, descargar el CV y dejar notas que solo ve el equipo. Cuando enseño este panel a una responsable de selección por primera vez, la cara que pone es la misma: "ojalá hubiera tenido esto hace tres años".

El módulo Flag añade la opción de marcar favoritos por usuario, así cada técnico arma su shortlist privada sin tocar el estado oficial. Y para empresas con procesos más formales, el módulo Workflow define transiciones controladas: por ejemplo, que solo un manager pueda mover una candidatura a "oferta enviada". Suena burocrático pero evita líos cuando hay varios reclutadores trabajando la misma vacante.

Conectar el Portal con el Resto del Ecosistema

Un portal aislado se queda corto. Si tu empresa ya usa un ATS, un ERP de RR.HH. o publica también en LinkedIn, Drupal se enchufa sin demasiado drama.

La API REST viene de serie y expone los tipos de contenido. Eso significa que portales externos pueden tirar de tus ofertas en tiempo real, y que tu ATS puede recibir las candidaturas sin que nadie las copie a mano. La Migrate API te salva si vienes de otra plataforma y necesitas traer el histórico de ofertas y candidaturas con su trazabilidad intacta.

Las notificaciones automáticas son donde se nota el trato humano. Cuando una candidatura cambia de estado, el candidato recibe un email personalizado, también si lo descartas. Esto se monta con Rules o con un módulo a medida que reaccione al hook de actualización. Avisar a quien no avanza, con un texto cuidado, mejora la reputación de la empresa como empleadora más que cualquier campaña de marca. Lo he visto en encuestas internas.

Para LinkedIn existe el módulo LinkedIn Integration o una conexión propia vía API que publica las ofertas en la página de empresa desde el panel de Drupal. Ahorra esa media hora diaria que ahora alguien dedica a copiar y pegar. Y Google Tag Manager se integra fácil para medir qué ofertas se ven, qué formularios se empiezan y dónde se abandona el proceso. Esos datos son los que llevas a la reunión mensual con dirección.

Seguridad, RGPD y Rendimiento: lo Aburrido que Evita Disgustos

Manejar datos de candidatos significa cumplir el RGPD a rajatabla. Lo mínimo que tu portal debe garantizar: consentimiento explícito en el formulario con enlace a la política y mención del responsable del tratamiento, acceso restringido a los datos solo para RR.HH., plazo de conservación definido (entre seis y doce meses suele ser razonable para candidaturas no seleccionadas) y un mecanismo para que el candidato solicite la eliminación de sus datos en cumplimiento del artículo 17.

Para automatizar la limpieza, Scheduler despublica nodos en la fecha que marques y una tarea cron puede anonimizar los datos personales pasado el plazo. Así no dependes de la memoria de nadie ni de un Excel que se actualiza en marzo y nunca más.

En rendimiento, los listados de ofertas son candidatos ideales para caché porque cambian poco. Con Internal Page Cache y Dynamic Page Cache bien configurados, las páginas se sirven al instante incluso cuando lanzas una campaña grande y te entran picos de tráfico. He vivido el caso de un cliente con cuarenta mil visitas en un día tras salir en prensa, y el servidor ni se inmutó.

Cuando el Portal Deja de Ser un Listado y se Convierte en tu Mejor Reclutador

Después de pasar por portales que cobran por publicación, hojas de cálculo que se descuajaringan y bandejas saturadas de CVs en PDF, montar el portal en Drupal sobre el dominio propio me cambió la forma de trabajar. Las candidaturas entran ordenadas en un panel que entiende cómo selecciono, las ofertas caducadas se retiran solas, los descartes salen con un email correcto y el equipo deja de pelearse con herramientas para hablar con personas. La marca empleadora deja de ser una frase de la web corporativa.

Si llevas tiempo aguantando un portal que no acompaña, o si todavía vas tirando con correos y plantillas sueltas, hablemos de cómo sería tu portal de empleo a medida y te contamos cómo enfocaríamos el proyecto en función de tu volumen de ofertas y tu estructura de selección.