Administrador de plataforma

Audience

Este artículo es para operadores de la plataforma GCM. Los administradores de iglesia deberían ver Usuarios y roles — la consola del administrador de plataforma es la cabina interna del personal, no parte del espacio de trabajo por iglesia.

El administrador de plataforma es la superficie exclusiva para operadores que se encuentra detrás de app.geniuschurchmanager.com/platform. Es la forma en que el equipo de GCM gestiona cada organización en la plataforma: quién está atrasado, por qué una edge function falló anoche, qué titular de la página de aterrizaje se publica en español, qué hará el cron de renovaciones mañana por la mañana a las 02:00. Es una capa React separada con su propio menú lateral (PlatformLayout), su propia compuerta RBAC y su propia postura de auditoría.

Quién puede iniciar sesión

Solo un usuario cuyo JWT lleva is_platform_admin: true o is_superadmin: true puede cargar cualquier ruta /platform/*. Tanto PlatformLayout como PlatformAdmin.tsx verifican usePermissions().roles al montar y redirigen a los no miembros del personal de vuelta a /. La reclamación del JWT es establecida por la edge function auth-hook desde el perfil del usuario, por lo que las promociones surten efecto en el siguiente inicio de sesión.

Hay dos niveles:

Rol	Lo que desbloquea
platform_admin	Lectura/escritura completa en cada organización, cada libro mayor de facturación, cada fila de auditoría. No puede promover a otros usuarios a platform_admin o superadmin.
superadmin	Todo lo anterior, más la capacidad de otorgar platform_admin y superadmin. Un trigger de la base de datos (trg_protect_platform_admin_role*) prohíbe degradar al último superadmin.

Si tu cuenta pierde ambas banderas, serás expulsado silenciosamente a / en el momento en que visites /platform — cierra sesión y vuelve a iniciarla después de cualquier cambio de rol, ya que lo que cuenta es el JWT.

Advertencia sobre la cuenta de demostración

La cuenta de demostración compartida en app.geniuschurchmanager.com ya no es administrador de plataforma. Para seguir las capturas de pantalla en esta sección necesitas una cuenta del personal que lleve la reclamación platform_admin. Pídele a un superadmin que provisione una si no tienes acceso.

Los seis grupos de navegación

El menú lateral está agrupado según el ritmo del trabajo del operador, no por orden alfabético:

1. Overview — KPIs generales, lista de organizaciones.
2. Plans & Modules — catálogo de planes, mapeo plan -> módulo. Mayormente de solo lectura tras el lanzamiento.
3. Billing — consola de operaciones de facturación, configuración de gateway, métricas de MRR / cancelación.
4. Content — plantillas de correo, plantillas de sitio web, plantillas de workflow, contenido de aterrizaje.
5. Settings — branding, manifest de PWA, DNS, canales, configuración de correo, slugs reservados.
6. System — usuarios, geografía (datos maestros), registro de auditoría, registro de errores.

Qué vive en qué tabla

La mayoría de las superficies en esta sección leen de una de tres tablas de alcance de plataforma:

• platform_audit_log — cada acción del personal: organización creada, plan cambiado, reembolso emitido, suplantación iniciada, suplantación_fallida. Capturada por useAppMode y por cada edge function de operaciones de facturación.
• platform_settings — almacén plano de clave/valor. Contiene branding (brand_title, brand_logo), copia de marketing (marketing_hero_title), enlaces sociales, el interruptor del tour guiado. Sin columna organization_id — son configuraciones de toda la plataforma.
• admin_impersonation — la fila de sesión que el RPC start_impersonation crea para que current_org_id() pueda transparentemente delimitar a un usuario del personal a la organización objetivo. La fila es lo que hace que RLS "simplemente funcione" durante la suplantación.

Cualquier cosa que parezca datos por organización (orgs, payment_history, línea de tiempo de auditoría, error_log) vive en las mismas tablas multi-inquilino que un administrador de inquilino tocaría — el personal simplemente ve cada fila en lugar del lote de una organización.

Solo lectura por defecto, auditoría de cada escritura por diseño

Las pestañas del administrador de plataforma se apoyan fuertemente en tres patrones:

• useQuery con caché para lecturas, por lo que actualizar es gratis y consistente entre pestañas.
• Campos de motivo en cada escritura destructiva — reembolsos, eliminaciones masivas, sobrescrituras de suscripción requieren todos un motivo de texto libre que se registra en platform_audit_log junto al correo del actor.
• Dry-run antes de cobrar — el diálogo de renovación tiene "Solo vista previa" por defecto para que puedas ver lo que el gateway haría antes de que se mueva el dinero.

Si una futura característica te permite cambiar el estado a nivel de plataforma sin un campo de motivo, trátalo como un bug.

A dónde ir después

Necesitas...	Artículo
Encontrar una organización por nombre, cambiar su plan o eliminar un duplicado	Organizaciones
Reembolsar un pago, arreglar una renovación atorada o rastrear un cobro fallido	Operaciones de facturación
Iniciar sesión en el espacio de trabajo de un cliente para reproducir un bug	Flujo de suplantación
Triar un pico de errores estilo Sentry	Registro de errores
Investigar "quién cambió qué, cuándo"	Registro de auditoría
Agregar un país, estado o ciudad faltante al selector de direcciones	Geografía (datos maestros)
Ajustar la copia del héroe de la página de aterrizaje o subir una nueva imagen OG	Contenido de aterrizaje