Concepto y arquitectura
Ministrium implementa multi-campus como un modelo jerárquico de dos niveles sobre la arquitectura multi-tenant.
Tenant (Iglesia)
└─ Campus 1
├─ Miembros / prospectos / familias
├─ Salones / kiosko
├─ Eventos y service plans
└─ Grupos celulares
└─ Campus 2
└─ ...Lo que es del campus vs de la iglesia
| Recurso | Vive en | Se comparte entre campuses |
|---|---|---|
| Miembro / prospecto | Campus | No (transferible) |
| Familia | Campus | No |
| Asistencia | Campus | No |
| Donación | Campus de origen | Reportable consolidada |
| Cuenta de Stripe | Iglesia | Sí (1 sola cuenta) |
| Plantillas de comunicación | Iglesia | Sí |
| Roles y permisos | Iglesia (definición) | Asignación es por campus |
| Plan y facturación | Iglesia | Sí |
| Branding básico | Iglesia | Sí |
| Logo / dirección | Campus | No (cada campus tiene el suyo) |
¿Por qué un solo Stripe?
Porque desde el punto de vista fiscal, la iglesia es una sola entidad. El EIN/NIT/RFC es uno, y los recibos 501c3 deben emitirse en nombre de la iglesia, no del campus. Cada donación se etiqueta con el campus de origen para reportes, pero el dinero llega a una sola cuenta bancaria.
Sólo si cada campus es una entidad legal independiente. En ese caso son dos iglesias en Ministrium, no dos campuses. Vea Stripe Connect.
Aislamiento de datos
A nivel de base de datos, cada query incluye organization_id y campus_id. Las políticas de RLS (Row-Level Security) verifican ambos. Un usuario scoped al campus Norte que intente leer un miembro del campus Centro recibe 404, no 403 — desde su perspectiva, el miembro no existe.
Reportes consolidados sin perder per-campus
Los reportes (asistencia, donaciones, salud) tienen un selector que cambia entre:
- Un campus específico: filtrado.
- Todos los campuses: agregado.
- Comparativa: lado a lado.
Sólo org_admin y finance ven la opción “todos” y “comparativa”.