Portal Recovery Visibility
Ask "how's recovery doing?", "which portal is busiest?", or "any anomalies?" across every public-facing portal — answered from the Portals recovery audit log. Read-only.
Why Public Portal Recovery Slips Through The Cracks
Public portals are the surfaces customers and candidates actually touch — but they're owned by different apps, log to different tables, and rarely get the dashboarding attention internal surfaces do. Portals Help Agent is the one prompt that knows about all of them.
Portal Recovery Failures Hide In Per-App Audit Logs
The Field Service customer portal logs to its own audit table. The candidate portal logs to another. Nobody runs a daily "are all the public portals healthy?" check. By the time somebody asks, the failure window is days old.
Rate-Limit Hits Look Like Noise Until They're An Attack
18 rate-limit hits in 24 hours, all from one IP, is a probe. The platform writes the rate_limited events; nobody reads them. Portals Help Agent turns "any anomalies?" into a real answer with the top offending visitors ranked.
Is The Candidate Portal Even Enabled For My Tenant?
For a multi-portal platform, the basic question — which portals are configured, which are available, which are actually enabled right now — requires opening four different app admin pages. One prompt should answer that.
Customers Complain About Lost Magic-Link Emails With No Investigation Path
A customer says "I never got the email." Support has no easy way to see whether the magic link was requested, sent, consumed, or failed for that specific identifier. The audit log has the answer — it's just not searchable from chat.
A Quiet Portal That Suddenly Spikes Looks Like Success Until It Isn't
The former-employee portal has averaged 12 recovery requests a week for months. This week it's at 340 and nobody noticed because nobody runs a "which portals jumped?" query. Half the time it's a legitimate campaign; the other half it's credential stuffing — and the difference matters.
Cross-Portal Patterns Stay Invisible Because Every App Owns Its Own Dashboard
The same IP probed the candidate portal Monday, the customer portal Tuesday, and the visitor surface Wednesday. Each app's dashboard sees one event. No surface stitches the three together until somebody manually exports each log and joins them in a spreadsheet — which nobody does.
Portals Help Agent At A Glance
Portals AI (Help)
Read-only Portals telemetry, status, and recovery audit search.
Inside Portals Help Agent — The Actual Capabilities
Every block below maps to a real tool the agent runs against your public portal recovery audit log and PublicPortalConfiguration rows. Read-only by design — the agent never toggles a portal, blocks an IP, or revokes a token.
Recovery Health In One Number, Then Drill Down
recovery_overview returns the rollup every dispatch / support team should check daily — totals for requested, sent, consumed, failed, and rate-limited events plus the send success rate. Configurable window from 1 to 90 days. The first answer to "how's recovery doing?"
- Recovery snapshot —
recovery_overviewwith configurablewindow_days(1-90, default 7). - Counts every event class — requested, sent, consumed, failed, rate-limited, plus the derived send success rate.
- Single rollup across all enabled portals — Field Service, candidate, former-employee, AI Front Office, the rest.
- The metric customers actually feel — send success rate maps directly to "did the magic link arrive?" complaints.
Know Which Portals Are On, Off, And Available
list_portal_status reads PublicPortalConfiguration — the same row the per-app admin UI writes to — and returns every portal with both available and enabled flags. The basic "is the candidate portal even on?" answered without opening four admin pages.
- List every portal —
list_portal_statusreadsPublicPortalConfiguration; same source as per-app admin UI. - Available vs enabled flags — distinguishes "could be turned on" from "is currently on".
- only_enabled filter — pass
only_enabled: truefor the live-and-running set. - Cross-app visibility — no app-by-app clicking; one call returns the whole public-facing surface.
Rank Portals By Recovery Activity
top_portals_by_volume ranks portals by recovery event count over a window — "which portal sees the most recovery requests this week?". Useful for sizing support capacity by surface and for catching unexpected traffic shifts (a quiet portal that suddenly tops the list usually means something changed).
- Top portals by volume —
top_portals_by_volumewith configurable window (1-90 days) and limit (1-25, default 5). - Recovery-event focused — counts the events that map to real user friction (magic-link requests, OTP requests).
- Trend signal — a quiet portal jumping to
- Capacity sizing — feed the rankings into how support staffing maps to portal owners.
Spot Anomalies Without Reading Raw Logs
recent_anomalies calls out the rate-limit hits, failed sends, and invalid-token events that nobody would otherwise notice — plus the top visitors (anonymous IP references) and identifier hashes behind them. The right first stop for "are we being probed?", "is anything broken?", and the morning sweep before standup.
- Recent anomalies —
recent_anomalieswith configurable hours window (1-168, default 24). - Top offending visitors and identifier hashes — surfaces the entities driving the anomaly so you can decide whether to escalate.
- Spans every public portal — one call covers Field Service, candidate, former-employee, AFO, etc.
- Drill-down ready — pair with
search_audit_logto pull raw rows for the visitors that look suspicious.
Search The Recovery Audit Log Without SQL
search_audit_log filters the public-portal audit log by portal key, event type, IP, a person's email or phone, and time window. Useful when a customer reports "I never got the email" and you need to know whether the magic link was requested, sent, consumed, failed, or rate-limited for their identifier.
- Search the audit log —
search_audit_logbyportal_key,event,ip,email,phone,window_hours(1-720, default 24). - Seven event types —
requested,sent,no_match,failed,rate_limited,consumed,invalid_token. - Per-IP investigation — pin to one IP after
recent_anomaliessurfaces it. - Read-only — it never changes a portal, a setting or a link.
Outcomes Teams Can Measure
Portals Help Agent's job is to make public-portal recovery a daily-tracked metric instead of an after-the-fact discovery. Measure against the pre-agent baseline so you can see what the agent surfaced first.
- Time-to-detection on portal recovery anomalies — median minutes from anomaly start to first agent surfacing.
- Send success rate across all enabled portals — the customer-felt metric, tracked daily instead of post-incident.
- Rate-limit hit rate — share of recovery requests that get throttled (and which visitors are driving the share).
- "Where is my magic link?" resolution time — median time from support question to a definitive answer pulled from the audit log.
- Portal status drift — share of "is X enabled?" questions answered in chat vs by clicking through per-app admin UIs.
Intentionally Read-Only · Telemetry, Not Configuration
Portals Help Agent has zero write tools. Six tools, all reads — recovery overview, portal status, volume ranking, anomaly detection, visitor traffic, audit log search. The agent never toggles a portal, edits branding, or changes a custom domain or a rate limit. Those changes are made by an admin on the Portals Catalog, Branding, Custom Domains and Identity & Recovery tabs, on purpose. Portals has no IP-block or token-revoke control.
- Zero write tools — 6 read tools; the agent never changes a portal's state.
- Changes stay with an admin — opening or closing a portal, branding, custom domains and rate limits are set on Portals' own tabs; what a portal contains is set in its owning app.
- Cross-portal read scope — one tool surface covers every public-facing portal the tenant has configured.
- Audit trail on every retrieval — even read calls log the requesting user and which tool ran.
WHAT TEAMS TRY INSTEAD
The four alternatives — and why none of them surface portal recovery telemetry across every public surface in one ask
Operations teams have been promised portal observability for years. The honest gap is that most options live on one portal at a time, surface uptime not recovery, or rely on a dashboard nobody opens until something is already on fire.
Pasting status questions into ChatGPT, Claude, or Copilot
General-purpose AI making sense of a copied uptime report
- Reads the live recovery audit log directly — no copy-pasted dashboard screenshots
- Cross-portal scope in one prompt — Field Service, candidate, former-employee, visitor, the rest
- Stays read-only by design — no risk of an AI accidentally toggling a portal
Salesforce Experience Cloud / HubSpot CMS health dashboards
Vendor-trapped portal telemetry tied to one customer surface
- Covers every portal the tenant runs — not just the CRM surface
- Reads from the Portals recovery audit log — not a vendor's analytics layer
- Works for portals the customer never bought a CRM seat for
Custom dashboards built on top of recovery logs
An ops team's quarterly project that nobody opens after the launch all-hands
- Plain-English answers without learning a Grafana board — how-is-recovery-doing returns in one prompt
- New portals appear automatically — no dashboard re-build when a new surface ships
- Anomalies surface conversationally instead of waiting for a threshold-based alert to fire
The manual fallback — ops checks each portal admin screen weekly
A routine that catches the obvious and misses the cross-portal pattern
- One ask covers every public portal — no five-tab tour
- Anomalies surface before the customer or candidate files a ticket
- Ops spends time on response, not status compilation
PLATFORM ADVANTAGE
Portals Help inherits everything dispatch already trusts
A standalone portal observability tool has to plumb identity, role gates, cross-portal scope, and audit. Portals Help gets all of it for free.
Read-only by design
Zero write tools. 6 read tools — the agent never changes a portal's state. Branding, custom domains and rate limits stay on Portals' own tabs, with an admin.
Cross-portal scope
One tool surface covers every public-facing portal the tenant has configured. New portals appear automatically.
Recovery-log grounded
Reads from the Portals recovery audit log — not a vendor analytics shadow copy.
Anomaly framing
Conversational anomaly detection — any-portal-anomalies, busiest-portal-this-week — without configuring threshold-based alerts.
Audit trail on every retrieval
Even read calls log the requesting user and which tool ran.
One agent, every portal
One read-only Portals agent answers status questions and assembles audit evidence across every portal in the catalog — one source of truth.
INDUSTRY FIT
Industries where portal observability moves the needle
Portals Help earns its keep where public surfaces are core to revenue, recruiting, or service delivery — and recovery telemetry is a leading indicator.
Retail
Loyalty and returns portals tracked together — recovery patterns visible across the customer-facing perimeter without dashboard hopping.
Healthcare
Patient and referral portals tracked cross-surface — anomaly framing catches recovery shifts before they become support tickets.
Financial Services
Customer and broker portals monitored together — supervision evidence ready when an auditor asks about portal availability.
Hospitality
Guest, partner, and visitor surfaces tracked from one ask — property GMs see anomaly patterns before service starts.
Manufacturing
Supplier and contractor portals tracked cross-surface — supply-chain ops sees recovery anomalies the day they appear.
Public Sector
There is no separate observability vendor to ship telemetry to. AI requests go to the platform's configured model providers.
WHY MANGOAPPS WINS
An embedded portals help agent beats a horizontal AI, a CRM-vendor health board, or a custom dashboard on every axis
The argument operations, IT, and customer success all share — and the one Salesforce or HubSpot structurally cannot answer.
Cheaper than the alternatives
No Experience Cloud add-on, no third-party portal observability vendor, no engineering team building a cross-portal dashboard.
More secure
Read-only by design, audit-trail on every call, no separate observability vendor. AI requests go to the platform's configured model providers, like every MangoApps agent.
Easier to deploy
Already deployed if Ask AI is on. Every portal the tenant has configured is in scope the same day — no per-portal integration.
Easier to use
Lives inside Ask AI. Plain-English how-is-recovery-doing returns in one prompt — no dashboard to learn, no alert to configure.
Easier to manage
New portals show up automatically. The agent's scope follows what dispatch already trusts — no manual scope registration.
Easier to extend
One Portals tool registry. A new telemetry tool (a new recovery shape, a new anomaly framing) ships once and covers every portal in the catalog.
AI is actually better
A horizontal AI can describe what portal observability should look like. Portals Help returns live cross-portal recovery telemetry, surfaces anomalies, and stays read-only — all from one prompt.
At our head office within HR, marketing, and finance, we use ChatGPT quite a bit, and MangoApps AI Helper is a useful tool for us. As I go around to the stores, I’ve been showing them how the AI Intranet Helper can find things and answer plain language questions about our resources, and they’re quite excited about that.
Alison van Zijl
Head of Human Resources
Full House
Customer Success
MangoApps Customers
Organizations that trust MangoApps to run every workflow across their workforce.
Webinars
Customer Case Studies
Customer Case Studies
Customer Case Studies
Customer Case Studies
Customer Case Studies
Frequently Asked Questions About Portals Help Agent
6 tools — recovery_overview (7d/30d/configurable totals + send success rate), list_portal_status (every portal with available + enabled flags), top_portals_by_volume (ranked recovery activity), recent_anomalies (rate-limit and failure spikes plus the top offending visitors), traffic_overview (page views, unique visitors and sessions per portal), and search_audit_log (filterable raw audit rows). All read-only.
No. There is one Portals agent, and it is read-only. The same six tools answer the daily "how's recovery doing?" check and assemble audit-grade evidence for a dispatcher or IT admin; the change itself is made by an admin: a portal is opened or closed on the Portals Catalog tab, and a token is revoked in the app that owns the portal.
No. The agent has no write tools — it surfaces the offending visitor via recent_anomalies as a reference you can pass to search_audit_log to drill into that visitor's raw rows, and points you at the Security or Audit Log tab for the real addresses. Portal rate limits are set on the Identity & Recovery tab, a portal is closed on the Catalog tab, and a token is revoked in the app that owns the portal.
PublicPortalConfiguration for status and the public-portal recovery audit log for events. Seven event types are tracked — requested, sent, no_match, failed, rate_limited, consumed, invalid_token — and each event carries portal key, IP, and identifier hash.
Time-to-detection on portal anomalies, send success rate across all portals, rate-limit hit rate, "where is my magic link?" resolution time, and the share of portal-status questions answered in chat vs by clicking through per-app admin UIs. Compare to your pre-agent baseline.
Let's Talk
Every team. Every employee. Every workflow. One AI platform — built for the frontline. Since 2008, trusted by 2 million+ users with an NPS of 78.
Why Choose Us?
- Frontline AI: Governed AI for every employee and workflow.
- Top Security: HITRUST, ISO & SOC 2 certified.
- Exceptional UX: Delightful on mobile and desktop.
- Proven Results: 98% customer retention rate.
Rolled out to every employee at AutoZone (125,000), PetSmart (50,000+), A.S. Watson and Raley's (20,000) — and at larger retailers we are not permitted to name.
Prefer to explore first? Ask AI about Portals Help AI Agent →