Gestión de formularios directamente en tu CMS

Introducción

Los formularios parecen simples hasta que un proyecto necesita más de uno.

En ese momento, los equipos suelen repetir el mismo trabajo una y otra vez: definir tipos de contenido para las respuestas, crear controladores, configurar validaciones, exponer endpoints y construir una experiencia de edición para que personas no técnicas puedan gestionar los campos. Todo ese trabajo es necesario, pero rara vez es lo que diferencia un producto.

strapi-plugin-form-builder-cms fue creado para eliminar esa repetición. En lugar de reconstruir la infraestructura de formularios en cada proyecto, el plugin ofrece a los equipos de Strapi una forma de modelar formularios dentro del CMS, gestionar campos desde el panel de administración y mantener el control sobre cómo las definiciones y envíos de formularios encajan en el resto de la aplicación.

Este artículo explica qué hace el plugin, por qué fue creado, cómo funciona y hacia dónde se dirige.

---

¿Qué es este plugin?

strapi-plugin-form-builder-cms es un plugin de Strapi para crear y gestionar formularios directamente dentro del CMS.

Su objetivo es claro: permitir que desarrolladores y equipos de contenido definan formularios sin tener que construir una solución personalizada desde cero para cada landing page, flujo de contacto, campaña de captación de leads, paso de onboarding o herramienta interna.

En términos generales, el plugin te permite:

• Crear formularios desde el panel de administración de Strapi
• Definir campos y tipos de campo de forma estructurada
• Mantener la configuración de formularios en el CMS en lugar de codificarla en el frontend
• Centralizar la lógica de formularios en un plugin reutilizable, evitando que quede dispersa por el proyecto
• Avanzar más rápido cuando un proyecto requiere múltiples formularios con estructuras diferentes

Esto hace que el plugin sea especialmente útil en sitios de marketing, productos SaaS, funnels multipágina, dashboards internos y cualquier proyecto donde los formularios son contenido, no simplemente interfaz de usuario.

---

Por qué lo construimos

La motivación detrás del plugin fue práctica, no teórica.

En proyectos reales de Strapi, los formularios aparecen en todas partes: páginas de contacto, secciones de newsletter, flujos de solicitud de demo, páginas de cotización, pipelines de contratación, listas de espera, solicitudes de soporte y flujos de onboarding. La primera implementación suele ser manejable. La tercera o cuarta se vuelve costosa.

El patrón repetitivo se veía así:

1. Crear un tipo de contenido para el formulario o sus envíos.
2. Decidir cómo almacenar y validar los campos.
3. Construir lógica personalizada en el panel de administración para que personas no técnicas puedan gestionar etiquetas, placeholders, opciones y estados requeridos.
4. Exponer los datos al frontend en un formato consistente.
5. Repetir la misma arquitectura para el siguiente formulario.

Esa repetición es exactamente el tipo de problema que un plugin debería resolver.

En lugar de reconstruir la misma infraestructura en cada proyecto, el plugin empaqueta el flujo de construcción de formularios en una extensión reutilizable de Strapi. El resultado: entregas más rápidas, menos código duplicado y una experiencia de edición mucho mejor para quienes gestionan el contenido a diario.

---

Cómo funciona por dentro

El plugin trata los formularios como datos estructurados del CMS, no como widgets aislados del frontend.

Esa decisión importa porque mantiene la configuración de formularios cerca del resto del modelo de contenido. Un formulario deja de ser un blob JSON ad hoc o un componente React hardcodeado: se convierte en una entidad gestionable dentro de Strapi.

La implementación se centra en cinco ideas clave:

1. Los formularios se modelan en el CMS

Cada formulario tiene su propia definición y metadatos: título, identificador, descripción, etiqueta del botón de envío y una colección de campos. Una vez que la estructura vive en Strapi, los editores pueden actualizar un formulario sin necesidad de un nuevo despliegue de código por cada pequeño cambio de texto.

2. Los campos se almacenan como objetos estructurados

En lugar de tratar los campos como marcado arbitrario, el plugin los almacena en un formato predecible. Cada campo puede tener propiedades como:

• name: nombre del campo
• label: etiqueta visible
• placeholder: texto de ayuda dentro del input
• type: tipo de campo
• required: estado obligatorio
• options: opciones seleccionables
• helpText: texto de ayuda o indicaciones de validación

Gracias a que los datos están normalizados, el frontend puede renderizar formularios dinámicamente desde la respuesta de la API, sin depender de componentes específicos para cada caso de uso.

3. El panel de administración se convierte en el constructor

Una de las partes más valiosas de un plugin de Strapi es que extiende la propia experiencia del CMS. Con este plugin, el panel de administración es el lugar donde los equipos configuran formularios, ajustan definiciones de campos y gestionan cambios con el tiempo.

Esto elimina un cuello de botella frecuente: cambios de contenido que deberían ser simples, pero que aún requieren intervención del desarrollador porque el esquema del formulario está enterrado en el código.

4. El frontend permanece desacoplado

El plugin no impone ningún stack de frontend específico. Una aplicación Next.js, un sitio Astro, un SPA en React o cualquier otro consumidor puede solicitar las definiciones de formularios a Strapi y renderizarlas según las necesidades del proyecto.

Esta separación es importante: el CMS es dueño de la estructura del formulario, mientras que el frontend es dueño de la presentación y la experiencia de envío.

5. El plugin es reutilizable entre proyectos

Una vez que la lógica de construcción de formularios vive dentro de un plugin, deja de ser una solución de un solo proyecto. Los equipos pueden reutilizar el mismo flujo de trabajo en múltiples builds de Strapi e iterar sobre una base compartida, en lugar de mantener copias ligeramente distintas del mismo sistema.

---

Flujo de trabajo típico

Una implementación estándar se ve así:

1. Instala strapi-plugin-form-builder-cms en tu proyecto de Strapi.
2. Abre el plugin desde el panel de administración de Strapi.
3. Crea un nuevo formulario: Contacto, Newsletter, Solicitud de Demo, Soporte, etc.
4. Añade los campos que tu caso de uso necesita.
5. Solicita la definición del formulario desde el frontend.
6. Renderiza el formulario dinámicamente en tu aplicación.
7. Gestiona los envíos según los requisitos de tu proyecto.

En la práctica, esto cambia el trabajo de "construir otro sistema de formularios personalizado" a "configurar y consumir una definición de formulario".

---

Ejemplo práctico

Este es el tipo de configuración de campos que el frontend puede consumir desde Strapi:

{
  "title": "Solicitar una Demo",
  "fields": [
    {
      "name": "fullName",
      "label": "Nombre completo",
      "type": "text",
      "required": true
    },
    {
      "name": "email",
      "label": "Correo corporativo",
      "type": "email",
      "required": true
    },
    {
      "name": "companySize",
      "label": "Tamaño de la empresa",
      "type": "select",
      "options": ["1-10", "11-50", "51-200", "201+"]
    }
  ]
}

El frontend puede iterar sobre los campos y renderizar los inputs de forma dinámica:

type Field = {
  name: string;
  label: string;
  type: string;
  required?: boolean;
  options?: string[];
};

export function DynamicForm({ fields }: { fields: Field[] }) {
  return (
    <form>
      {fields.map((field) => {
        if (field.type === "select") {
          return (
            <label key={field.name}>
              {field.label}
              <select name={field.name} required={field.required}>
                {(field.options ?? []).map((option) => (
                  <option key={option} value={option}>
                    {option}
                  </option>
                ))}
              </select>
            </label>
          );
        }

        return (
          <label key={field.name}>
            {field.label}
            <input
              name={field.name}
              type={field.type}
              required={field.required}
            />
          </label>
        );
      })}
    </form>
  );
}

Lo importante no es el JSX en sí. Lo importante es que la definición del formulario ahora está dirigida por Strapi, lo que hace que la integración sea mucho más fácil de mantener cuando los requisitos cambian.

---

Hoja de ruta

El roadmap de un plugin de formularios está naturalmente impulsado por proyectos reales. Algunas áreas especialmente prometedoras son:

• Reglas de validación más ricas y lógica de campos condicional
• Mejor gestión y filtrado de envíos
• Integraciones con webhooks para CRMs, plataformas de email y herramientas de automatización
• Presets de campos para casos de uso comunes
• UX de administración más pulida para formularios grandes
• Soporte más robusto para configuraciones multilenguaje y multitenant

El plugin ya resuelve un problema concreto, pero hay espacio para crecer hacia una capa de operaciones de formularios más completa dentro de Strapi.

---

Cómo contribuir

Si trabajas habitualmente con Strapi y los formularios aparecen una y otra vez en tus proyectos, vale la pena probar este plugin.

Puedes instalarlo, probarlo en un flujo de trabajo real y aportar feedback basado en experiencia concreta de implementación. Las contribuciones más valiosas suelen ser las más específicas:

• Reportes de bugs con pasos reproducibles
• Feedback de UX de editores que usen el panel de administración
• Propuestas para tipos de campo faltantes o reglas de validación
• Ejemplos de integración con frontends
• Pull requests que mejoren la fiabilidad o la extensibilidad

Los plugins de comunidad mejoran cuando se moldean a partir del uso real, no de listas de features genéricas.

Si strapi-plugin-form-builder-cms te ahorra tiempo o resuelve un problema de gestión de formularios en tu stack, úsalo, compártelo y contribuye al proyecto.