Platform administration

From Tenants in the top nav, click New tenant. The form asks for the four things the platform needs to bootstrap the ecclesia:

• Name — the human-readable ecclesia name (“Riverwood Ecclesia”). Shown to members throughout the app.
• Subdomain — the DNS label that becomes subdomain.cdroster.com. Lowercase, DNS-safe, and immutable after create.
• Timezone — IANA name (Australia/Sydney, Europe/London, and so on). Drives every “when is this meeting?” conversion downstream.
• Administrator email — the person who’ll become the ecclesia’s first administrator. On create they receive an invitation email with a one-time activation link (they set their own name when they activate).

Save. The tenant lands in the list with an Invitation sent chip. Once the first admin activates and signs in, they take over — you don’t usually touch the tenant again until an operations request comes in.

Sometimes an ecclesia administrator asks for help debugging something they can’t reach from inside their own tenant. Support grants let you (or another platform admin) act inside their tenant for a time-boxed window without becoming a long-term member.

On the tenant’s detail page, open the Support grants section and click New grant. Enter:

• Reason — free text; recorded on the audit event. Something the tenant admin will recognise if they see it in their audit log later.
• Permissions — ticked capabilities the grant will carry. Read-only for “look at their data”; toggle write elevation for “fix something”.
• Duration — how long the grant is valid, in minutes. Common presets: 30, 60, 120.

Save. The grant appears in the tenant’s Support grants list with an Active chip and a countdown. Redeem it from the same row to launch a session on the tenant’s subdomain; grants auto-expire at the deadline and can be revoked earlier.

Under Operations → Migrate person. The async flow moves a person’s profile + login from one tenant to another — the classic case is someone moving ecclesias without wanting to start their sign-in from scratch.

Fill in:

• Person ID — the UUID of the person in the source tenant. Get it from a support session or the source admin.
• Source + destination tenants — picked from the dropdown (list is seeded from the Tenants catalogue).
• Reason — recorded on the audit event. “Family moved to Sydney; consent recorded on 2026-07-04” is the kind of thing you want on the record.

Queue the migration. It runs on the worker; the page polls the status every two seconds and renders the lifecycle queued → running → complete (or failed with a friendly message).

What moves: profile, contact points, and the person’s login + password. What stays behind: household, roles, qualifications, availability, and roster history — the destination admin re-configures those. MFA does not carry over; the person re-enrols in the destination on first sign-in. The source person is archived and their login is disabled (not deleted).

Under Operations next to the migration tool. The SMTP smoke test queues a synthetic email through the deployed SMTP relay — useful after rotating credentials or when a tenant reports that their invitations aren’t arriving.

Click Send test email. The server sends synchronously and toasts the result:

• Green toast: the relay accepted the message. Delivery to the final inbox depends on the recipient’s mail system; if the relay accepts but nothing arrives, look at the recipient side (spam filters, DKIM / SPF mismatches, corporate mail policy).
• Red toast: the relay rejected. The toast carries the SMTP error text; check the credentials and the relay’s allow-list.

The body of the test email is a short status payload. Nothing about the tenants in the database leaves the server — this is a delivery check, not a data test.

Every platform-admin action leaves an audit trail. Open the tenant’s Audit log from its detail page and filter by action name (“migrate”, “support_grant_create”, “tenant_update”) or by subject to answer “who did what, when, and why”.

A design decision worth knowing: the audit log records field names, not values. So a row shows “given_name, address” rather than “John, 92 Lansdowne Street”. That’s deliberate — it keeps the audit useful for accountability without turning the log into a data-exfiltration vector.