Portals
1. What it is
Portals is the single place to see and manage every public-facing portal your organization runs — the Candidate Portal, Customer Support Portal, Former Employee Portal, Guest Pass check-in, public forms, and more. Each of those portals is owned by its own app, but none of them can show you all the others. Portals fills that gap.
From Portals an admin can browse a catalog of all portals, toggle each one on or off, configure the shared identity-recovery layer (the OTP and magic-link system that external visitors use to prove who they are), review a security feed of suspicious activity, apply unified branding, map custom domains, and view traffic analytics — all in one app instead of app by app.
- Enablement: Portals requires a licence. An admin enables it in Admin → Apps Marketplace. Access is controlled through Portals app-admin assignment, not a configuration-driven role list.
- What it is not: Portals does not replace each app’s own portal settings. It is the umbrella view and the shared infrastructure (branding, recovery, domains). App-specific configuration — such as which jobs appear on the career site or which forms are public — stays in the owning app.
2. Standing it up
- Go to Admin → Apps Marketplace, find Portals, and enable it.
- Open Portals → Catalog. The catalog lists every portal whose owning app is licensed for your organization. Verify the portals you want are showing as Enabled. Toggle any you do not need off.
- Open Portals → Identity & Recovery. Review the rate-limit window (default 60 minutes) and the maximum recovery requests per identifier per window (default 5). These settings govern every portal that uses the shared OTP / magic-link layer.
- Open Portals → Branding if you want a consistent look across all branded portals. Upload your logo, set colours and fonts. Changes apply immediately to every portal that uses the shared branded layout.
- Grant Portals app admin to any additional users who should access admin-only tabs (Identity & Recovery, Security, Audit Log, Branding, Custom Domains, Settings). Without app-admin status, a user sees only the Dashboard and the Catalog.
Silent-until-paired warning: enabling Portals does not enable any individual portal. A portal appears in the Catalog only when its owning app is licensed. If you enable Portals but have not licensed Job Board, for example, the Candidate Portal row will not appear.
3. How it fits together
Catalog vs. owning app. The Catalog is the registry of all portals in your organization. It draws from a fixed list of 33 registered portal surfaces grouped into 13 categories (Recruiting, HR, Learning, Safety, Engagement, Forms, Documents, Facilities, Scheduling, Communications, Support, Field Service, and General). Only the portals whose owning app is currently licensed appear as toggleable. The Catalog controls whether a portal is reachable; the owning app controls what the portal contains.
Toggling a portal off in the Catalog makes it unreachable even if the owning app is still enabled. That is the key distinction: the owning app decides what a portal shows; the Catalog decides whether it is accessible at all.
For example: Job Board owns the Candidate Portal, Job Listings, and Job Alerts portals (all in the Recruiting category, grouped under the Career Portal heading). If all three are licensed and enabled in the Catalog, visitors can reach them. Disabling Candidate Portal in the Catalog leaves Job Listings and Job Alerts accessible while blocking candidate logins — without touching Job Board’s own settings.
When you save the Catalog with a filter active (by category, status, or search), only the portals visible on the current page are written. Portals hidden by the filter keep their previous state, so filtering does not accidentally disable everything out of view.
Identity & Recovery is the shared authentication layer for external visitors. When a candidate, former employee, or customer requests a magic link or OTP to verify their identity, the request flows through this layer. It enforces a per-identifier sliding-window rate limit and logs every event into a hashed audit trail. Events are one of six types: requested, sent, consumed, failed, rate-limited, or invalid token. Identifiers (email addresses and phone numbers) are stored only as SHA-256 hashes — never as plaintext — so accessing the audit log does not expose contact information.
A nightly rollup job aggregates audit events by portal and day into daily summaries. A separate nightly prune job deletes raw audit records and daily rollups older than the configured retention period. The rate limit and retention settings you configure in Identity & Recovery apply to every portal that uses the recovery layer.
Portal Hub is the public landing page at /portals that lists every enabled portal for external visitors. It uses the shared branding you configure and lets visitors navigate to the portal they need without knowing a direct URL. Portal groups (such as the Career Portal group containing Job Listings, Candidate Portal, and Job Alerts) are displayed together under a shared heading.
Branding is a single set of logo, colours, fonts, header/footer text, and optional custom HTML/CSS shared by every portal that uses the branded layout. One edit here updates every branded portal simultaneously. Branding defaults to Off until an admin enables it. The branding record is versioned — the last 20 changes are visible on the Branding page, providing a history of who changed what.
Custom Domains let you map your own hostnames (e.g. careers.acme.com) to a specific portal or to the full platform. Each domain is unique across all organizations. Verification works through a DNS TXT record: you add a token at _mangoapps-verify.<your-domain>, then click Verify. Once verified, the domain can be activated to start routing traffic. A nightly background job re-checks DNS for every active domain and alerts admins if the TXT record has drifted. The job does not automatically deactivate the domain — it warns so you can investigate whether the DNS change was intentional.
Two analytics surfaces. Recovery Analytics (under the Recovery Analytics tab) charts the daily trend of recovery events — requested, sent, consumed, failed, rate-limited — over 7, 30, or 90 days, with a per-portal breakdown table. Traffic Analytics (under the Traffic Analytics tab) shows page views, unique visitors, sessions, bounce rate, device breakdown, and top pages across all portals, with date-range presets from today through the current year. Both are admin-only.
4. Running it
Reviewing the portal catalog
Go to Portals → Catalog. Each row shows the portal name, owning app, category, and enabled/disabled status, with a preview link when available. Filter by category (e.g. Recruiting, HR, Documents) or status (enabled, disabled, unavailable), or search by name. To change which portals are active, toggle the switches and save. Only portals whose owning app is licensed can be toggled — unlicensed portals appear as unavailable and cannot be turned on from here.
Saving applies only to the portals currently visible after filtering, so you can safely save a filtered view without affecting portals hidden by the filter.
Checking recovery health
The Dashboard shows a 7-day snapshot of recovery activity: total events, links sent, links consumed, rate-limited requests, failures, and a success rate. Top portals by recovery volume and a count of anomalies (failures, rate-limited, invalid-token events) appear at a glance. A getting-started card appears for new installations until the first real recovery event is recorded.
Monitoring security signals
Go to Portals → Security (admin only). The Security tab surfaces derived signals from recovery audit data over an adjustable time window (default 24 hours):
- Repeat-failure IPs — addresses generating the most failed, rate-limited, or invalid-token events.
- Identifiers near lockout — hashed identifiers with the most flagged events, with a count of how many portals each has touched.
- Cross-portal patterns — a single identifier requesting recovery across two or more different portals.
- Recent invalid-token events — the latest attempts to use an expired or forged link.
A background monitor runs every 15 minutes and sends a notification to Portals admins if flagged events spike above 25 in an hour. The alert fires once per spike, not repeatedly.
Reviewing the audit log
Go to Portals → Audit Log (admin only). Filter by portal, event type, IP address, identifier, or date range. The log shows 50 rows per page. Identifiers are stored as hashed values, not plaintext — to search, enter the original email or phone and the system hashes it for matching. Export the filtered set as CSV (capped at 10,000 rows per export).
Updating branding
Go to Portals → Branding (admin only). Upload a logo (PNG, JPEG, or WebP, up to 2 MB), favicon (PNG or ICO, up to 1 MB), or background image (up to 5 MB). Set primary and secondary colours, header background and text colours, header and footer text, and choose from 20 available Google Fonts. Custom CSS (up to 10,000 characters) and custom header/footer HTML (up to 50,000 characters each) are available when Enable custom HTML is turned on. Click Revert to defaults to restore factory settings and remove uploaded assets.
Managing custom domains
Go to Portals → Custom Domains (admin only). Click New custom domain, enter the hostname and select a purpose (the full platform, a specific portal, or careers). A verification token is generated automatically. Add a DNS TXT record at _mangoapps-verify.<your-domain> with the token value, then return and click Verify. Once verified, activate the domain. To take a domain offline without deleting it, click Deactivate. A domain must be re-verified if you change the hostname.
Viewing traffic analytics
Go to Portals → Traffic Analytics (admin only). The dashboard shows total page views, unique visitors, sessions, bounce rate, average time on page, and pages per session for the selected date range. Filter by portal to drill into a single surface. Use the date-range picker (today, yesterday, last 7 days, last 30 days, this month, last month, this year). Per-portal detail pages show the same metrics scoped to one portal. Export the current view as CSV.
Mobile access
The Portals dashboard, Audit Log, and Security views are available on mobile at /m/apps/portals. Branding, Custom Domains, Settings, and Traffic Analytics remain desktop-only. Phone-class devices are automatically redirected from the desktop dashboard to the mobile view.
5. Settings
Portals has two settings surfaces. Settings controls which sub-surfaces are visible. Identity & Recovery controls the recovery layer’s thresholds.
Sub-surface toggles (Portals → Settings)
| Setting | Default | What it changes |
|---|---|---|
| Portals AI Agent (Ask AI) | On | Whether the Portals agent answers questions in Ask AI |
| Portal catalog | On | Whether the Catalog tab appears |
| Analytics rollups | On | Whether the Recovery Analytics and Traffic Analytics tabs appear |
| Identity & Recovery configuration | On | Whether the Identity & Recovery tab appears |
| Security signals | On | Whether the Security tab appears |
| Recovery audit log | On | Whether the Audit Log tab appears |
| Portal branding | On | Whether the Branding tab appears |
| Custom domain mappings | On | Whether the Custom Domains tab appears |
All toggles default to On. Turning a toggle off hides the tab from navigation and blocks access to its controller routes — a user who bookmarks the URL will be redirected to the dashboard with a message explaining the feature is not enabled.
Settings are stored per-organization. The Sample Data section at the bottom of the Settings page lets you generate a small set of synthetic recovery audit events so you can preview the Audit Log and Identity & Recovery dashboards before real traffic arrives. The sample data is safe to regenerate or remove at any time.
Identity & Recovery thresholds (Portals → Identity & Recovery)
| Setting | Default | What it changes |
|---|---|---|
| Window (minutes) | 60 | The sliding window over which recovery requests are counted per identifier |
| Max attempts per identifier per window | 5 | How many recovery requests one identifier can make before being rate-limited |
| Retention (days) | 180 | How long audit records and daily rollups are kept before the nightly prune job deletes them |
These three settings are shared across every portal that uses the recovery layer. Per-portal overrides are not exposed in the UI.
6. More help
- Portals FAQ — specific setup and operating questions
- Ask AI — the assistant answers questions about Portals from these articles.