Portal Posture For IT Admins
Portals Admin Agent is the audit-and-assemble surface for everyone responsible for public portals. The same five tools that drive the Help agent's daily check power deeper investigation here — turn an anomaly into a structured evidence packet and hand the actual fix to the owning app's admin UI. The agent never blocks an IP, never revokes a token, never toggles a portal.
Why Auditing Public Portals Becomes A Patchwork Job
Public portals live across multiple owning apps. Audit asks one set of questions, ops asks another, support asks a third — and nobody assembles the answer the same way twice. Portals Admin Agent makes the assembly itself a tool.
Audit Asks "Show Me Every Failed Magic Link Last Quarter" And You Build A Spreadsheet
The data is in the audit log. The query is straightforward — portal in (...), event = failed, time window — but the standalone admin UI doesn't compose those filters. Quarterly audits become a one-week build-the-export project.
Anomaly Spikes Get Discovered Days Late
The candidate portal had nine delivery failures across one weekend, all to a decommissioned email domain. Nobody noticed until a candidate emailed support on Monday. Anomaly detection that doesn't run against every portal every day produces this exact failure mode.
Ownership Isn't Obvious — Which Team Fixes A Field Service Portal Rate-Limit Spike?
Is it Field Service? Is it Platform? Is it the IT admin? The right owner depends on what the anomaly turns out to be. Without an evidence packet, the question bounces between three teams before anyone acts.
"Did The Customer Get The Email?" Is Asked Without An Audit Trail Path
The support agent on the phone needs to know whether the magic link was requested, sent, consumed, failed, or rate-limited for one specific identifier. The standalone audit UI is not optimized for that question. Five minutes of pre-agent time becomes 30 seconds with one prompt.
Rate-Limit Tuning Is A Hunch Instead Of A Data-Backed Decision
The portal got hit by a scraping wave last quarter; the throttle was tightened by hand and never revisited. Legitimate customers are now bumping into the cap during seasonal peaks. Tuning it correctly needs a rolling view of request rates by IP class, but the data only gets pulled when a complaint escalates — so the policy stays mis-tuned in between incidents.
Cross-Portal Outage Postmortems Stitch Logs By Hand
Tuesday's incident spanned the Customer Portal, the Service Desk public form, and the Field Service quote intake — all hit by the same upstream identity-provider blip. Each portal logs into a different surface. The retro doc takes a day to assemble because the events have to be aligned by timestamp across three audit tables, then narrated by hand.
Portals Admin Agent At A Glance
Portals AI (Admin)
Audit-grade evidence assembly across every public portal. Read-only by design.
Inside Portals Admin Agent — The Actual Capabilities
Every block below maps to a real tool the agent runs against the public-portal audit log and PublicPortalConfiguration. The agent assembles; the human owner acts in each app's admin UI. There are no per-portal write tools in this agent — by design.
Cross-Portal Posture In One Snapshot
recovery_overview + list_portal_status together answer the morning-standup question — "how is every public portal doing right now?" Send-success rate across the full surface, which portals are enabled, which are in the attention zone, and the dominant signal driving the attention call.
- Recovery overview — recovery_overview rolls up requested / sent / consumed / failed / rate-limited across every public portal.
- Portal status — list_portal_status from PublicPortalConfiguration; the same row each per-app admin UI writes to.
- Send-success rate as the headline metric — directly tracks "did the magic link arrive?" complaints.
- Attention triage — combined snapshot calls out which portals deviate from baseline before drill-down.
Anomaly Detection That Produces An Evidence Packet, Not Just A Number
recent_anomalies surfaces the rate-limit spikes, delivery failures, and invalid-token events plus the top offending IPs and identifier hashes — and then search_audit_log pulls the raw rows behind them. Together they form the evidence packet a human owner needs to make the call on what to do next.
- Recent anomalies — recent_anomalies with configurable hours window (1-168, default 24); returns counts plus top offending IPs / identifier hashes.
- Per-IP investigation — pin to an IP from the anomaly result and drill into raw audit rows via search_audit_log.
- Six event types covered — requested, sent, failed, rate_limited, consumed, invalid_token.
- Evidence packet ready for hand-off — the agent's output is structured exactly how an IT admin / dispatcher needs it for the actual fix.
Volume Ranking To Decide Where Engineering Effort Goes
Not every portal carries the same load — and the load shifts. top_portals_by_volume ranks portals by recovery activity, so capacity decisions (rate-limit thresholds, SES quota, support staffing) get made against actual usage rather than gut feel.
- Top portals by volume — top_portals_by_volume with configurable window (1-90 days) and limit (1-25, default 5).
- Capacity sizing input — rank → SES quota / rate-limit ceiling / on-call staffing decisions.
- Trend canary — a low-volume portal jumping to the top usually signals a config change worth investigating.
- Pairs with portal status — combine ranking with available/enabled flags to spot portals running hot OR running silent.
Audit-Log Drill-Down Without Writing SQL
search_audit_log takes portal key, event, IP, and window as filter axes and returns up to 50 rows newest-first. Useful for compliance walk-throughs (every failed magic link last quarter), incident response (everything from this IP since the spike), and front-line support questions (every event for this identifier hash).
- Search the audit log — search_audit_log by portal_key, event, ip, window_hours (1-720, default 24).
- Up to 50 rows newest-first — limit (1-50, default 20) keeps results scannable.
- Per-identifier visibility — pull every event tied to one identifier hash for the "where is my magic link?" support pattern.
- Compliance-grade — every retrieval logs the requesting admin, the tool, and the parameters; the audit log of the audit-log access.
Hand Remediation To The Owning App's Admin UI · Always
The agent assembles; it never executes. RISKY_TOOLS is empty by design. IP blocks, token revokes, custom domain edits, branding changes, and per-portal toggles all live in each owning app's admin UI. The agent's job is to make the hand-off cheap by packaging the evidence the human needs to act.
- RISKY_TOOLS is empty — zero write tools; the agent never changes a portal's state.
- Per-portal writes stay in the owning app — Field Service customer portal in Field Service admin; candidate portal in Recruiting admin; etc.
- Recommended-owner output — the evidence packet calls out which app's admin should take the action.
- Audit trail on every retrieval — even read calls log the requesting admin and the parameters used.
Outcomes Teams Can Measure
Portals Admin Agent's job is to shrink the time from "anomaly detected" to "right owner has a complete evidence packet" — and to make audit walk-throughs a one-prompt affair instead of a one-week project. Measure against your pre-agent baseline.
- Time-to-evidence-packet — median minutes from "anomaly detected" to a structured packet handed to the right owner.
- Compliance-question turnaround — median hours for "show me every failed send last quarter" type asks vs the pre-agent build-an-export baseline.
- Anomaly false-positive rate — share of recent_anomalies calls that escalated to action vs spurious spike.
- Cross-portal coverage — share of public portals whose recovery health is checked daily (the agent makes this trivially possible).
- Right-owner-first-touch rate — share of evidence packets that reach the correct owning team without being re-routed.
Intentionally Read-Only · Same Tools, Audit-Driven Framing
Portals Admin shares the same five-tool registry as Portals Help, by design — the difference is framing, not capability. Both surfaces are read-only. The admin framing emphasizes evidence assembly, audit drill-downs, and right-owner hand-off. The day-to-day "how's it doing?" snapshot lives in the Help agent.
- RISKY_TOOLS is empty — by design; this agent assembles evidence, it doesn't act on it.
- Same tool registry as Portals Help — both read from Agents::ToolRegistry::Portals; the difference is the prompt framing and the kind of question being asked.
- Cross-portal scope — every public portal the tenant has configured is in the same query surface.
- Audit-trail-on-audit — agent read calls themselves log the requesting admin, useful for SOC2 and tenant-specific compliance asks.
WHAT TEAMS TRY INSTEAD
The four alternatives — and why none of them assemble portal evidence across every public surface in one pass
Most teams audit each portal separately — one tool for the customer portal, another for the candidate portal, a third for the visitor surface. The honest gap is that an attacker doesn't respect those boundaries and neither should the audit.
Pasting recovery logs into ChatGPT, Claude, or Copilot
General-purpose AI making sense of a copied audit dump
- Reads the live recovery audit log directly — no paste, no truncation, no PII in a vendor chat window
- Cross-references every public portal in one query — not one chat per surface
- Assembles a structured evidence packet ready to hand to the owning app admin, not prose
Salesforce Experience Cloud AI / HubSpot CMS AI
Vendor-trapped portal AI tied to one customer surface
- Covers all portals the tenant runs — customer portal, candidate, visitor, former-employee — 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 evidence-assembly scripts run by IT
A SOC analyst paging through SQL and tail-ing logs in a terminal
- Same evidence in plain English without console access — fewer eyes on raw recovery logs
- Structured handoff to the owning app admin built in — no copy-pasting evidence into a Jira ticket
- New portals show up the day they ship — no script update required
The manual fallback — IT clicks through five portal admin screens
A weekly audit that takes half a day and still misses cross-portal patterns
- Cross-portal anomalies surface in one prompt instead of five screen tours
- Evidence packets assemble themselves — IT confirms and forwards instead of compiling from scratch
- No portal slips through because the asker forgot it existed
PLATFORM LEVERAGE
Portals Admin Agent inherits everything dispatch already enforces
A standalone portal audit tool has to plumb identity, role gates, audit logging, and cross-portal scope. Portals Admin Agent gets all of it for free.
Same registry as Portals Help
Both agents read from Agents::ToolRegistry::Portals. Help asks how is recovery doing; Admin asks show me the anomaly evidence — same source of truth.
Cross-portal scope
Every public portal the tenant has configured is in the same query surface — Field Service, candidate, former-employee, visitor, and the rest.
Evidence-assembly framing
Structured output ready to hand to the owning app admin. The agent never blocks an IP, never revokes a token, never toggles a portal.
Read-only by design
RISKY_TOOLS is empty. By design — this agent assembles evidence and the human decides the remedy in the owning app's UI.
Audit-trail-on-audit
Agent read calls themselves log the requesting admin. Useful for SOC2, ISO 27001, and tenant-specific evidence asks.
Role-aware reads
Portal-admin role gates are honored at the tool layer. Reads return only what the asking admin is entitled to see in the owning app.
INDUSTRY FIT
Industries where portal audit matters most
Portals Admin Agent shines where public-facing surfaces are central to revenue, recruiting, or service delivery — and the audit consequences of a missed anomaly are real.
Retail
Loyalty and returns portals audited cross-surface for the same recovery pattern that fraud teams already chase manually.
Healthcare
Patient and referral portals — recovery anomalies surfaced in one pass for HIPAA-relevant evidence collection.
Financial Services
Customer and broker portals audited together for the audit committee — quarterly access review evidence ready before the auditor asks.
Hospitality
Guest, partner, and visitor surfaces audited together — anomalous recovery patterns visible across the property's full digital perimeter.
Manufacturing
Supplier and contractor portal audits compiled with structured evidence packets — useful when supply-chain risk surfaces in a security review.
Public Sector
FedRAMP-eligible deployment options with portal audit evidence staying inside the tenant boundary — no third-party security vendor in the data path.
WHY MANGOAPPS WINS
An embedded portal admin agent beats a horizontal AI, a CRM-vendor add-on, or a SOC script library on every axis
The argument IT, security, and operations all share — and the one Salesforce or HubSpot structurally cannot answer.
Cheaper than the alternatives
No Experience Cloud AI add-on, no SOC contractor retainer for portal evidence assembly, no engineering team building a cross-portal audit framework.
More secure
Role-aware reads, zero writes, audit-trail-on-audit. Evidence stays inside the tenant boundary; no third-party security vendor in the data path.
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 in the same UI IT and security admins already use. Cross-portal evidence in plain English, no terminal session required.
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 Help. New tools (a new audit pattern, a new evidence shape) ship once and both agents benefit.
AI is actually better
A horizontal AI can describe what portal evidence should look like. Only Portals Admin Agent can assemble it across every public surface, cite the recovery log, and structure the handoff to the owning app admin.
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 Admin Agent
5 tools shared with Portals Help — recovery_overview, list_portal_status, top_portals_by_volume, recent_anomalies, and search_audit_log. All read-only. The admin framing emphasizes evidence assembly (anomaly + audit drill-down + recommended owner) and compliance walk-throughs over the day-to-day "how's recovery?" snapshot.
By design. Public-facing portals are owned by different apps — Field Service customer portal in the Field Service admin, candidate portal in the Recruiting admin, etc. The writes live in each owning app's admin UI so the responsible team makes the call. This agent assembles the evidence the human needs.
Same tool registry, different framing. Portals Help is for the daily "how's it doing?" check and the front-line "where is my magic link?" support pattern. Portals Admin is for audit walk-throughs, compliance evidence assembly, and the IT admin / on-call workflow where the agent's output gets handed to the owning team for action.
Yes — that's exactly the workflow. recent_anomalies surfaces the top offending IPs, then search_audit_log with the ip filter pulls every event tied to that IP across the configurable window (up to 720 hours). The agent then recommends the owning team to take the actual block in their admin UI.
Time-to-evidence-packet on anomalies, compliance-question turnaround (vs the build-an-export baseline), anomaly false-positive rate, cross-portal coverage, and right-owner-first-touch rate. All measured against 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:
