Portals App Overview

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 → All Apps. 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

1. Go to Admin → Apps → All Apps, find Portals, and enable it.
2. Open Portals → Catalog. The catalog lists every portal whose owning app is licensed for your organization. Check that the portals you want are switched on — the row reads Enabled, or Open for a portal that also opens through its own app. Off in its app or Open here · off in its app means that app’s own switch still keeps the portal shut — the line beneath names the setting; turn it on there. Toggle off any portal you do not need.
3. 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.
4. Open Portals → Branding if you want a consistent look across all branded portals. Upload your logo, set colors and fonts. Changes apply immediately to every portal that uses the shared branded layout.
5. Grant App admin for Portals to anyone else who should manage portals. Portals is open to Admins, Super Admins and people granted App admin for Portals — every tab. Anyone else is turned away at the door with “Portals is available to administrators only.”

Silent-until-paired warning: enabling Portals does not enable any individual portal. Every registered portal has a row in the Catalog, but a portal whose owning app is not licensed is marked Unavailable and cannot be switched on. If you enable Portals but have not licensed Job Board, for example, the Candidate Portal row stays Unavailable until Job Board is licensed.

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 seven types: requested, sent, no match, consumed, failed, rate-limited, or invalid token. Identifiers (email addresses and phone numbers) are stored only as a one-way hash keyed to your organization — 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, colors, 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. There is no on/off switch: until you customize something, every portal follows your workspace’s Brand & Theme, and any setting you leave blank keeps following 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 DNS record. A hostname that is not verified within 30 days of being added is released, and its page shows the date. Once verified, the domain can be activated. A Careers domain opens your public job board and a Main domain sends visitors to your MangoApps sign-in page; a domain set aside for another single portal does what Main does — it does not open that portal’s own page yet. 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.

Many portals open through their owning app as well (a survey’s link, a paired kiosk, a Drive share link). Their rows show Open or Closed: switching one off closes its public page, and switching it on leaves it to the owning app as before. A separate List on your public portals page box decides whether that portal also appears as a tile on your public portals page. Turning a portal on never lists it by itself.

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: how many people asked for a sign-in link or code (recovery requests), how many were sent and how many were used, and a send success rate. The busiest portals by recovery events (named as the Catalog names them, each opening its rows in the Audit Log) and a count of anomalies (failures, rate-limited and 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 notifies your Portals admins in-app and by email when the flagged events in one hour reach the alert threshold set on Identity & Recovery (default 25), unless Recovery abuse alerts is switched off in Settings. 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 the portal colors, header background and text colors, header and footer text, and fonts. Custom header/footer HTML (up to 50,000 characters each) is available when Use custom header & footer HTML is turned on; a custom stylesheet saved before can be removed but is no longer edited here. Click Match workspace brand to clear your portal-only settings so every portal follows Brand & Theme again.

Managing custom domains

Go to Portals → Custom Domains (admin only). Click Add 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 DNS record — within 30 days, or the hostname is released. 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, pages per session and — on portals that measure it — average time on page, 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 tabs are shown, the two security alerts and the Portals assistant. Identity & Recovery holds the four numbers that govern the recovery layer.

Switches (Portals → Settings)

Setting	Default	What it changes
Enable Portals AI Agent	On	Whether the read-only Portals assistant answers in Ask AI. It answers only for Portals admins.
Show portal catalog	On	The Catalog tab, and with it the on/off switches for public portals. Portals already open stay open while it is off.
Analytics rollups and traffic analytics	On	The Recovery Analytics and Traffic Analytics tabs. Nightly rollups and visitor tracking keep running either way.
Identity & Recovery effectiveness signals	On	The 30-day effectiveness figures on the Identity & Recovery page. The page itself and its limits are never hidden.
Security signals tab	On	The Security tab. Alerting is the separate switch below.
Recovery abuse alerts	On	The in-app and email alert when recovery failures spike. Independent of the Security tab.
Recovery audit log	On	The Audit Log tab, its CSV export and the recovery figures on the dashboard. Events keep being recorded and pruned either way.
Portal branding	On	The Branding tab. Your portals keep their branding while it is off.
Custom domain mappings	On	The Custom Domains tab. Verified, active hostnames keep resolving while it is off.
Custom domain drift alerts	On	The alert when a live custom domain stops passing DNS verification. Independent of the Custom Domains tab.

Turning a tab’s switch off hides it from navigation; a bookmarked link to it returns to the Portals dashboard with a message naming the switch. Both alerts go to your Portals admins, and each person can mute them for themselves under Portal Security Alerts in their notification preferences — one switch there covers both alerts.

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 events are counted per identifier (5–1,440)
Max recorded recovery events per identifier per window	5	The rate limit (1–20). Each recovery attempt records two events — the request and its outcome — so the default of 5 allows 3 attempts per window; the page shows the number of attempts your setting allows
Alert threshold (flagged events per hour)	25	How many failed, rate-limited or invalid-token events in one hour, across your whole business, trigger the recovery abuse alert (5–500)
Retention (days)	180	How long audit records and daily rollups are kept before the nightly prune job deletes them (7–3,650)

These four 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.