Portal Recovery Visibility
Portals Help Agent is the read-only telemetry surface for every public-facing portal — Field Service customer portal, candidate portal, former-employee portal, AI Front Office visitor surface, and the rest. Ask "how's recovery doing?", "which portal is busiest?", "any anomalies?" — and get answers from the same recovery audit log dispatch already trusts.
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 IPs 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_overview with configurable window_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_status reads PublicPortalConfiguration; 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: true for 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_volume with 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 IPs 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_anomalies with configurable hours window (1-168, default 24).
- Top offending IPs 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_log to pull raw rows for the IPs 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, 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_log by portal_key, event, ip, window_hours (1-720, default 24).
- Six event types — requested, sent, failed, rate_limited, consumed, invalid_token.
- Per-IP investigation — pin to one IP after recent_anomalies surfaces it.
- Read-only — never blocks IPs, never invalidates tokens; that work lives in the per-portal app admin UI.
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 IPs 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's RISKY_TOOLS list is empty. Five tools, all reads — recovery overview, portal status, volume ranking, anomaly detection, audit log search. The agent never toggles a portal, blocks an IP, revokes a token, edits branding, or changes a custom domain. Those writes live in each owning app's admin UI on purpose.
- RISKY_TOOLS is empty — 5 read tools; zero writes; the agent never changes a portal's state.
- Per-portal writes stay in the owning app — branding edits, custom-domain CRUD, IP blocks, token revokes all live in each portal's admin UI.
- 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 requesting user, tool, and parameters for compliance walk-throughs.
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 same audit log dispatch already trusts — 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 LEVERAGE
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
RISKY_TOOLS is empty. 5 read tools, zero writes — the agent never changes a portal's state. Branding edits and token revokes stay in the owning app.
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 same recovery audit log dispatch already trusts — 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, tool, and parameters. Compliance walk-throughs and SOC2 evidence ready by default.
Same registry as Portals Admin
Both agents read from Agents::ToolRegistry::Portals. Help asks status questions; Admin assembles evidence — same 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
FedRAMP-eligible deployment options with telemetry staying inside the tenant boundary — no third-party observability vendor in the data path.
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, telemetry stays inside the tenant boundary. No vendor outside the perimeter has portal data.
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
Shares the tool registry with Portals Admin. New telemetry tools (a new recovery shape, a new anomaly framing) ship once and both agents benefit.
AI is actually better
A horizontal AI can describe what portal observability should look like. Only Portals Help can return live cross-portal recovery telemetry, surface anomalies, and stay 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
Related Customer Stories
Customer Case Studies
Video Case Studies
Customer Case Studies
Customer Case Studies
Customer Case Studies
Customer Case Studies
Frequently Asked Questions About Portals Help Agent
5 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 top offending IPs), and search_audit_log (filterable raw audit rows). All read-only.
They share a tool registry today — both surfaces read from Portals::TOOLS — but the Help framing is for the daily "how's recovery doing?" check, while the Admin framing is for deeper audit-driven remediation work where the agent's job is to assemble evidence for a human dispatcher / IT admin. Same underlying registry, different prompts and different user expectations.
No. RISKY_TOOLS is empty — the agent surfaces the offending IP via recent_anomalies and lets you drill into raw rows with search_audit_log, but the actual block / token revoke / portal toggle all live in the per-portal app admin UI where the tenant's owning team makes the call.
PublicPortalConfiguration for status and the public-portal recovery audit log for events. Six event types are tracked — requested, sent, 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
Since 2008, we've been building the workforce platform — earning the trust of 2 million+ users and an NPS of 78.
Why Choose Us?
- AI-Powered Platform: The most unified workforce experience on the planet.
- Top Security: HITRUST, ISO & SOC 2 certified.
- Exceptional UX: Delightful on mobile and desktop.
- Proven Results: 98% customer retention rate.
Trusted by Legendary Companies:
