Portals
Umbrella surface for every public-facing portal — catalog, identity & recovery, audit log, and analytics across all app-owned portals.
MangoApps
Overview
Portals is the umbrella that gives every public-facing portal in your business a single home. Each app keeps owning its own portal feature (Field Service its Customer Portal, Recruiting its Candidate Portal, Offboarding its Former Employee Portal, AFO its visitor surface, eSig its kiosk, Drive its public links) — but the cross-cutting concerns live here. Catalog lists every portal with status, owning app, public URL, and "open preview" links. Identity & Recovery is the single home for the OTP / magic-link recovery layer (PortalIdentityRecovery concern) — configure rate limits, masking rules, lockout thresholds applied uniformly to every portal that opts in. Audit Log is a searchable browser over PortalRecoveryAudit, filterable by portal, event, identifier hash, or IP, with CSV export. Analytics rolls up cross-portal visit counts, recovery requests, success rate, and conversion. The umbrella does not own per-portal enable toggles — those stay in the owning app where they belong; Catalog reads them, never writes.
Highlights
Capabilities
Catalog & Discovery
-
Cross-app portal catalog (PublicPortalConfiguration registry)
-
Status badges (enabled / disabled / requires-token / public-link)
-
One-click preview link to each portal
-
Jump-to-owning-app settings
Identity & Recovery
-
Unified PortalIdentityRecovery concern (magic-link + OTP variants)
-
Per-portal recovery method override (where supported)
-
Sliding-window rate limiting per identifier per portal
-
Identifier hashing (SHA-256 — no plaintext email/phone in audit)
-
Configurable rate-limit window + max attempts
Audit Log
-
PortalRecoveryAudit browser with date / portal / event filters
-
IP and user-agent capture per request
-
CSV export of filtered audit results
-
Configurable retention (default: 180 days)
Analytics
-
Cross-portal recovery rollup (nightly DailyRollupJob)
-
Trend charts: requested / sent / consumed / failed / rate-limited
-
Per-portal totals over a 7d / 30d / 90d window
-
Unique-identifier counts per portal per window
Security
-
Repeat-failure IP feed (top N over a tunable window)
-
Identifiers near lockout (most flagged events per identifier)
-
Cross-portal access patterns (one identifier hitting many portals)
-
Recent invalid-token events
Branding
-
Per-business defaults: logo (Active Storage), primary + accent color, font
-
Portal title, support email, footer text
-
Live preview of branding while editing
Custom Domains
-
Hostname → portal mappings (PortalCustomDomain model)
-
Per-domain verification token for DNS TXT record
-
Lifecycle: pending → verified → active (or revoked)
-
DNS / TLS / edge routing handled by ops (model captures intent)
Limits & Specs
-
Default rate-limit window: 60 minutes (configurable)
-
Default max attempts: 5 per window per identifier (configurable)
-
Default audit retention: 180 days (configurable)
-
Default recovery method: Magic link (per-portal override possible)
-
Allowed roles: Admin, Super Admin
Use cases
Resources
FAQ
No. Each owning app keeps its own portal enable toggle (Field Service has customer_portal_enabled, Recruiting has candidate-portal config, etc.). Portals only reads — the catalog surfaces state from each app, but flipping a portal on or off still happens in the owning app's settings. This keeps the source of truth where the feature lives.
Three things: (1) the default recovery method (magic-link vs OTP) for portals that support both; (2) rate-limit thresholds for the PortalIdentityRecovery concern; (3) audit retention. Per-portal overrides are possible — the umbrella sets defaults, individual portals can override.
Every recovery event (request, send, failure, rate-limit, consume, invalid-token) is logged with timestamp, IP, user-agent, and SHA-256 hash of the identifier — never plaintext. Configurable retention (default 180 days). CSV export available. For SOC 2 / HIPAA-style audits this is generally sufficient; check with your compliance team for industry specifics.
Two reasons. First, packaging it as an app gives it real surface area — admins discover it, configure it, see analytics. An invisible "platform feature" gets ignored. Second, it gates behind a license so it ships as part of the platform tier rather than free-with-everything; the value (cross-portal control, audit, analytics) justifies the gate.
You probably don't need Portals yet. The umbrella adds the most value when you have three or more public-facing portals; under that, the owning app's built-in settings are usually enough.
