main content
< Volver a blog sobre aplicaciones móviles

Portal de empleo con Drupal: módulos y configuración

Como crear un portal de empleo y gestion de candidaturas con Drupal

El reclutamiento ya no vive en los anuncios de prensa. Vive en URLs, formularios y dashboards. Los datos de InfoJobs lo confirman: el 92% de las ofertas de empleo en España se publican exclusivamente en canales digitales. Y hay un segundo número que pesa más en el comité de dirección: las empresas que operan su propio portal recortan hasta un 35% el coste por contratación frente a quienes dependen solo de plataformas externas. Drupal 10 entrega la flexibilidad para montar ese portal con gestión de candidaturas integrada, automatización del flujo y una experiencia de uso que mira de frente a cualquier SaaS especializado.

Vamos al grano. En esta guía detallamos la arquitectura técnica, los módulos imprescindibles y las configuraciones concretas para levantar un job board profesional sobre Drupal.

Arquitectura de contenido: tipos de contenido y taxonomias

Antes del primer módulo, el modelo de datos. Una mala estructura ahora se paga cara dos años después, cuando hay 4.000 ofertas cerradas y nadie sabe filtrarlas. En Drupal 10, esa estructura se traduce en content types y vocabularios de taxonomía bien definidos.

Tipo de contenido: Oferta de empleo

Crea un content type llamado job_posting con los siguientes campos:

  • Titulo del puesto (field_job_title): campo de texto plano, obligatorio.
  • Descripcion del puesto (body): campo de texto con formato largo, con CKEditor 5 configurado para listas y encabezados.
  • Ubicacion (field_location): referencia a taxonomia locations con terminos jerarquicos (Comunidad Autonoma > Provincia > Ciudad).
  • Tipo de contrato (field_contract_type): lista de opciones (Indefinido, Temporal, Practicas, Freelance, Media jornada).
  • Rango salarial (field_salary_range): dos campos numericos (minimo y maximo) en euros brutos anuales.
  • Departamento (field_department): referencia a taxonomia departments.
  • Fecha de publicacion y Fecha de cierre (field_publish_date, field_closing_date): campos de tipo fecha.
  • Estado de la oferta (field_job_status): lista (Abierta, En proceso, Cerrada, Cubierta).
  • Empresa (field_company): referencia a entidad si el portal es multi-empresa, o campo oculto si es corporativo.

Tipo de contenido: Perfil de candidato

Si los candidatos pueden mantener un perfil persistente, suma un content type candidate_profile vinculado al usuario. Dos rutas: el módulo Profile, o un campo entity reference al user. Elige según convenga al equipo de mantenimiento.

  • Nombre completo, Email de contacto, Telefono.
  • CV adjunto (field_cv): campo de archivo que acepte PDF y DOCX, con limite de 5 MB.
  • Experiencia y Formacion: campos de texto largo o, mejor aun, paragraphs con el modulo Paragraphs para estructurar multiples entradas.
  • Habilidades (field_skills): referencia a taxonomia skills, con widget de autocompletado y seleccion multiple.

Formularios de candidatura con Webform

Webform (drupal.org/project/webform) es la pieza central de la gestión de candidaturas. La tentación inicial es crear un content type para cada solicitud. Mal camino. Webform permite diseñar formularios flexibles sin escribir código y persistir cada envío como una entidad consultable, exportable y conectable.

Configuracion del formulario de candidatura

  1. Instala Webform y sus submodulos: drush en webform webform_ui webform_node webform_attachment -y.

  2. Crea un webform llamado job_application con estos elementos:

    • Nombre completo (textfield, obligatorio).
    • Email (email, obligatorio, con validacion).
    • Telefono (tel).
    • Puesto al que aplica (hidden): se prerrellena automaticamente con el titulo de la oferta mediante token [current-page:title] o un campo computed.
    • Carta de presentacion (textarea, maximo 2000 caracteres).
    • CV adjunto (managed_file, extensiones permitidas: pdf docx, tamaño maximo: 5 MB).
    • Aceptacion RGPD (checkbox, obligatorio, con enlace a la politica de privacidad).
  3. Configura los handlers de Webform:

    • Email handler: envia un correo de confirmacion al candidato y otro de notificacion al reclutador con los datos del envio y el CV adjunto.
    • Remote post handler: si necesitas enviar los datos a un ATS externo via API REST.

Vincular el formulario a cada oferta

Dos opciones limpias. La primera: el módulo Webform Node Element, que inyecta el formulario en la plantilla del content type job_posting. La segunda: el webform como bloque en la región adecuada. En ambos casos, el campo hidden y los tokens de Drupal asocian el envío a la oferta sin intervención humana. ¿Quieres trazabilidad nativa? Añade un entity_reference en el webform para vincular cada submission directamente al nodo de la oferta.

Vistas y listados con Views

Views vive en el core de Drupal 10 y resuelve los listados con filtros avanzados sin una línea de código.

Vista principal del portal de empleo

Crea una vista de tipo Content, filtrada por content type job_posting y estado Abierta. Configura:

  • Filtros expuestos: ubicacion (select jerarquico con Better Exposed Filters), tipo de contrato (checkboxes), departamento (select), rango salarial (slider con el modulo Views Exposed Form Widgets).
  • Ordenacion: por fecha de publicacion descendente como predeterminado, con opcion de ordenar por relevancia si integras Search API.
  • Formato de resultado: tarjetas (cards) con titulo, ubicacion, tipo de contrato y fecha, usando Views Bootstrap o un template Twig personalizado.
  • Paginador: Ajax pager para navegacion sin recarga completa.

Panel del reclutador: candidaturas recibidas

Crea una vista de tipo Webform Submissions filtrada por el formulario job_application. Columnas: nombre del candidato, email, fecha de envío, puesto al que aplica y un enlace directo para descargar el CV. Suma filtros expuestos por puesto y por fecha. Ese panel se vuelve la cabina del reclutador.

Con el módulo Webform Views integras las submissions dentro de Views y aplicas todo el arsenal: filtrado, ordenación y exportación a CSV o Excel con Views Data Export. Operativa diaria resuelta.

Roles de usuario y permisos

Drupal 10 permite definir roles granulares que se adaptan perfectamente a un portal de empleo:

  • Candidato (candidate): puede registrarse, crear y editar su perfil, enviar candidaturas, ver el estado de sus envios.
  • Reclutador (recruiter): puede crear, editar y cerrar ofertas de empleo, ver y gestionar las candidaturas recibidas para sus ofertas, descargar CVs, cambiar el estado de las candidaturas.
  • Administrador de RRHH (hr_admin): acceso completo a todas las ofertas y candidaturas, puede gestionar usuarios reclutadores, exportar datos, acceder a informes.

Configura los permisos en /admin/people/permissions. Si necesitas separar ofertas por departamento o filial, monta el módulo Group para que cada reclutador solo vea las candidaturas de su área. Aislamiento limpio, sin scripts custom.

Flujos de trabajo automatizados con ECA y Rules

ECA (Event-Condition-Action) es el sucesor de Rules en Drupal 10. Automatiza procesos sin código y sustituye horas de operativa manual:

  • Cierre automatico de ofertas: cuando field_closing_date llega a la fecha actual, ECA cambia field_job_status a "Cerrada" y despublica el nodo.
  • Notificacion al candidato: cuando el reclutador cambia el estado de una candidatura (por ejemplo, de "Recibida" a "En proceso" o "Descartada"), ECA envia un email personalizado al candidato.
  • Alerta de nueva candidatura: cada vez que se recibe un webform submission del formulario job_application, ECA notifica al reclutador asignado.
  • Recordatorio de ofertas sin actividad: si una oferta lleva 15 dias sin recibir candidaturas, ECA envia un aviso al reclutador para que revise la descripcion o amplie la difusion.

Instala ECA con drush en eca eca_base eca_content eca_user -y y modela los procesos desde la interfaz gráfica en /admin/config/workflow/eca. Sin tocar PHP.

Integracion con sistemas ATS externos

La mayoría de organizaciones ya tienen un Applicant Tracking System operativo: Greenhouse, Lever, Teamtailor, Factorial. Drupal convive con ellos en tres modos:

  • Webform Remote Post: envia los datos de cada candidatura como JSON a la API del ATS. Configura el handler con la URL del endpoint, las cabeceras de autenticacion (API key o Bearer token) y el mapeo de campos.
  • Migrate API: para importar ofertas desde el ATS al portal Drupal, usa el modulo Migrate Plus con un source plugin JSON o XML que lea la API del ATS y cree nodos job_posting automaticamente.
  • Modulo Feeds: alternativa mas visual a Migrate para importaciones periodicas desde feeds RSS o JSON.

Patrón habitual: las ofertas nacen en el ATS, viajan a Drupal para la web pública, y las candidaturas recibidas en Drupal regresan al ATS para que RRHH gestione todo desde una única herramienta. Una sola fuente de verdad, dos canales.

SEO para ofertas de empleo: Schema.org JobPosting

Google for Jobs solo indexa ofertas con datos estructurados JobPosting. Es la diferencia entre aparecer en el carrusel destacado de Google o no existir. El impacto es medible: hasta multiplicar por 3 la visibilidad de tus ofertas en resultados de búsqueda.

Usa el modulo Schema.org Metatag o el modulo Schema.org Blueprints para añadir automaticamente el markup JSON-LD a cada nodo job_posting. Los campos obligatorios del schema son:

  • title: titulo del puesto.
  • description: descripcion completa.
  • datePosted: fecha de publicacion.
  • validThrough: fecha de cierre.
  • hiringOrganization: nombre y logo de la empresa.
  • jobLocation: direccion con addressLocality, addressRegion, addressCountry.
  • employmentType: FULL_TIME, PART_TIME, CONTRACTOR, etc.
  • baseSalary (recomendado): rango salarial con moneda.

Cierra el bloque SEO configurando Pathauto para generar URLs limpias del tipo /empleo/[field_location]/[field_job_title] y activa el módulo XML Sitemap para incluir todas las ofertas abiertas en el sitemap. Pequeños ajustes, ganancia grande en rastreo.

Busqueda avanzada con Search API y Solr

Si tu portal supera las 500 ofertas activas, la búsqueda nativa de Drupal se queda corta. Lentitud, relevancia pobre, sin facetas reales. Search API con backend Solr o Elasticsearch resuelve el problema:

  • Busqueda full-text con relevancia ponderada: el titulo del puesto pesa mas que la descripcion.
  • Facetas (Facets module): filtros dinamicos por ubicacion, tipo de contrato, rango salarial, departamento, con contadores en tiempo real.
  • Autocompletado (Search API Autocomplete): sugerencias mientras el usuario escribe.
  • Busqueda por sinonimos: "programador" encuentra tambien "desarrollador" y "developer".

Search API + Facets + Solr eleva el portal a una experiencia de búsqueda equiparable a LinkedIn o InfoJobs. Mismo estándar, sin dependencia de terceros.

Lo que un portal de empleo en Drupal aporta frente a soluciones SaaS

Construir el portal en Drupal en lugar de alquilar Teamtailor o Lever cambia la ecuación en cuatro frentes: propiedad total de los datos de candidatos (crítico para cumplimiento RGPD), personalización ilimitada de los flujos de trabajo, integración nativa con la web corporativa para coherencia de marca, y la eliminación de cuotas mensuales por volumen de ofertas o candidaturas que en plataformas SaaS pueden superar los 300 euros al mes para empresas medianas. Multiplica esa cifra por 36 meses y el caso de negocio se construye solo.

Si necesitas diseñar un portal de empleo adaptado a las necesidades de tu organizacion, contacta con nuestro equipo de Drupal para definir la arquitectura, los modulos y la integracion con tus herramientas de RRHH actuales.

Contacta con nosotros
Fila 1