rConfig Vector Prism – Admin Guide

rConfig Vector Prism Admin Guide: Day-to-Day Operator Workflows

This guide is for Prism Administrators — the engineers who run the platform. It covers what each admin surface does, the typical workflow for adding customers and users, where to look when something goes wrong, and which settings to revisit periodically.

If this is a new install, work through Getting Started first. The deeper, version-specific operator runbooks live inside the running instance at /admin/docs.

The Admin Sidebar

The admin sidebar is organized into three regions below the dashboard:

• Customers & Teams — Customers, Users, Tag mappings.
• Admin & Settings — Brand settings, System settings, System optimization, Audit log, Access audit, Exception logs, rConfig API logs, Horizon, Log viewer, Operator docs.
• Utility — Onboarding, Help center, Feedback, Settings, user menu.

The same sidebar surface is decided by your is_prism_admin flag. Admin users can also drop into the customer portal at any time (it’s the same authentication, different surface). Non-admin users see the customer portal only and get a 403 if they URL-hack into /admin/*.

Admin Dashboard

The admin dashboard at /admin is your at-a-glance health view.

User and team count cards — total counts, linked into the relevant management screens.

Notifications panel — surfaces actionable signals: API failures detected in the last 24 hours, open exception count, recent permission denials, mail server health. Each item links to the related management screen and (where applicable) a relevant /admin/docs page.

Onboarding card — gamified progress through the twelve setup tasks. New installs land here; once complete, the card collapses but stays accessible from the sidebar.

Activity feed — recent admin actions (user invited, brand updated, tag mapping changed) so you can see at a glance what’s been happening on the platform.

Managing Customers

The Customers screen at /admin/teams is where each tenant lives. One customer = one team.

Creating a Customer

Click Create customer. You’ll need:

• Name — the customer-facing label.
• Primary email — the contact for that team. Used as the to address on team-level notifications.
• Status — Active, Suspended, or Archived. Suspended teams keep their data but block sign-in for all members. Archived teams are hidden from default lists.
• Notes — internal-only.

After saving, you land on the team detail page. From here you can edit the team, invite the first user, and jump straight to the tag-mapping editor.

Suspending or Archiving

Set status to Suspended when you need to temporarily lock out a customer (non-payment, security incident, contractual reason). Their users will see a “team suspended” notice on next sign-in attempt; their data is preserved.

Set status to Archived when an engagement ends but you need to keep the audit trail. Archived teams don’t appear in sidebar workspace switchers; admins see them only in the customer list with the Archived filter applied.

Managing Users

The Users screen at /admin/users is where admin and customer users live in one global list.

Inviting a User

Click Invite user, pick a team, enter the email, and save. Prism queues a branded invitation email with a 24-hour signup link. The recipient sets a password and enrols 2FA.

If the invitation expires before they accept, click Resend on the user row. A fresh link is queued.

Resetting Two-Factor

If a customer user loses their authenticator and has used all their recovery codes, click Reset 2FA on their row. Prism clears their stored 2FA secret and queues a notification email. On next sign-in they’ll be sent through the enrollment flow again.

This action is logged with user.two_factor_reset in the audit log.

Disabling, Deleting, Promoting

• Disable — soft-locks the user without deleting any data. Useful for off-boarding while preserving audit context. Can be re-enabled.
• Delete — hard-removes the user. Their audit rows persist (showing the email at the time of action) but their account is gone.
• Promote to Prism admin — toggles is_prism_admin. The user gets the admin sidebar on next sign-in. Don’t forget to demote them when they leave the operator team.
• Promote to team primary contact — gives them the right to invite teammates and manage their team page on the portal.

Tag Mappings

The Tag mappings screen at /admin/tag-mappings is the gate that controls what each customer can see. There are no devices in Prism’s database — tag mappings drive every device list and config view by filtering the rConfig API response.

Danger

Tag management is the single most important security control in Vector Prism, and it is the service provider’s sole responsibility.

Tag mappings are the only mechanism that isolates one customer’s devices and configurations from another’s. An incorrect, over-permissive, or untested tag mapping will cause cross-tenant data leakage — a customer will see devices, configurations, and credentials that belong to another customer. Once that happens, the affected configurations must be treated as compromised: passwords, SNMP communities, pre-shared keys, and any secrets contained in the leaked configs need to be rotated.

Vector Prism enforces the tag-scope check faithfully on every request, but it cannot validate that the intent of a mapping is correct. Only the operator knows which tags belong to which customer.

You — the service provider running this Vector Prism instance — are responsible for:

• Defining a tag taxonomy in rConfig that maps cleanly to your customers (one customer-specific tag per customer is the recommended pattern).
• Confirming, before mapping, that every device carrying a candidate tag genuinely belongs to that customer.
• Verifying every new mapping by signing in as a member of the team (or impersonating one) and confirming the device list matches the contracted scope.
• Re-verifying mappings whenever rConfig tags are added, renamed, merged, or applied to new devices.
• Auditing mappings on a recurring schedule (quarterly at minimum) and after any rConfig administrative change that touches tags.
• Treating any over-exposure incident as a security event with notification, remediation, and post-incident review.

rConfig Inc. provides the platform; rConfig Inc. does not validate, audit, or guarantee the correctness of your tag mappings, and accepts no liability for data leakage caused by operator misconfiguration. Your contract with each customer carries the data-handling commitments — the configuration that honours those commitments is yours to maintain.

Mapping Workflow

1. Open /admin/tag-mappings and pick a team.
2. The detail page shows two panels: Available rConfig tags (fetched live from your rConfig server, cached five minutes) and Mapped tags (currently bound to this team).
3. Use the search box on the available panel to filter.
4. Click Add to map a tag. The change is immediate; the customer’s next portal page load reflects the new scope.
5. Click Remove to unmap. A confirmation dialog spells out the consequence.

Choosing a Tag Strategy

The cleanest pattern is one customer-specific tag per customer (e.g. cust:acme), applied in rConfig to every device that customer owns. Map only that tag. Device-type or location tags can be added on top, but the customer-specific tag is the source of truth.

Avoid mapping broad tags (production, core, wan) unless you really mean to expose every device carrying that tag to the team. Tag mappings compose with OR semantics: a device matching any mapped tag is visible.

Caution

A team with zero mapped tags sees zero devices. This is intentional fail-closed behaviour. After creating a team, the first thing to check if the customer reports an empty portal is that the tag mapping isn’t blank.

Brand Settings

Instance-Wide Branding

/admin/brand-settings controls the look and feel for every login screen, every portal page, and every email — unless a team override applies.

What you can edit:

• Logos — light + dark variants, plus a separate login logo and favicon.
• Login background — image with zoom and opacity controls.
• Colours — primary and accent picker (OKLCH-based) with WCAG contrast indicator.
• Typography — heading and body font family.
• Border radius scale — controls the corner rounding across the UI.
• Default colour scheme — light, dark, or system. Users can override per-session.
• Identity strings — instance name, short name, app title, footer text.
• Support links — support email, support URL, feedback URL, help URL, settings URL, company URL, company legal name.
• Login copy — message, headline, subline.
• Promo card — title, body, CTA label and URL (shown on the dashboard sidebar).
• “Powered by rConfig” toggle — show or hide the attribution line.
• Per-team override toggle — enables the per-team branding screen.

A live preview shows the login screen and a dashboard tile with your changes applied. Save is immediate; Reset to preset drops back to the seeded defaults; Save as preset stores your current settings as a named preset you can reapply later.

Per-Team Branding

If you’ve enabled per-team branding (see above), each team’s detail page exposes a Branding sub-page at /admin/teams/{id}/branding with the same fields. Any field left blank falls back to the instance default. The team’s portal renders the override; the admin surface always uses the instance brand to avoid confusion.

This is the headline white-label feature for MSPs delivering Prism as a service to many customers.

System Settings

/admin/system-settings is a tabbed power-user screen. Each tab is documented in detail in /admin/docs inside your Prism instance.

Mail Server

SMTP host, port, encryption, credentials, from address. The Send test email button queues a branded confirmation to your admin address. Failures appear in Exception Logs.

rConfig API

Base URL (FQDN only — no path), API token, TLS verification toggle. The Test rConfig button probes /api/v2/dashboard/health-latest and reports green/red plus response time. After a successful test, the sidebar clock widget begins comparing Prism’s wall clock to rConfig’s.

Exception Alerts

Email alerts on unhandled errors. Tab fields: enabled toggle, to address, HTTP status filter (typical: 413,500,502,503,504), throttle window (minimum 15 minutes recommended). The Send test exception alert button fires a mock alert.

Locale & Time

BCP-47 locale and IANA timezone. Applied instance-wide. Affects all UI date formatting, audit log timestamps, email templates.

Audit Retention

Two retention windows:

• Admin audit log — default 730 days (two years).
• Access audit — default 90 days.

A scheduled job runs daily and purges rows older than the window. Set a value to 0 to disable auto-purge for that log; manual bulk purge from the corresponding admin screen still works.

System Optimization

/admin/optimization reads your PHP runtime configuration and scores it against production recommendations. Each row is green (pass), amber (warn), or red (fail).

Revisit this screen after any PHP upgrade or php.ini change. The linked /admin/docs pages explain why each setting matters and what value to use.

Audit Log and Access Audit

Two separate logs share the same table but filter by action type at read time.

Audit Log

/admin/audit-log records every admin change: team created, user invited, tag mapping added, brand setting saved, 2FA reset, etc. Each row shows the action, the actor, the IP, the timestamp, and a metadata column with before/after state.

Filters: action type, user, date range. Free-text search on metadata. Export to CSV. Bulk purge by date range.

Access Audit

/admin/access-audit records every login attempt and every permission denial. Useful for security review: a user with twelve denials in a day is either confused, mistyping, or probing.

Same filters and export tooling.

Tip

Both logs are GDPR-relevant. Configure retention in System Settings → Audit Retention. Two years for admin actions and 90 days for access events is a reasonable starting point; tune to your jurisdiction and contracts.

Exception Logs

/admin/exception-logs shows uncaught HTTP exceptions with deduplication. Identical exceptions (same class, message, file:line) within a day increment a counter rather than creating duplicate rows.

Each row shows state badge (open / resolved), HTTP status, count, first occurrence, last occurrence. Click to expand and see the full stack trace and request context. Mark resolved to hide it from the default view; reopen if it recurs.

Use this screen as the first stop when a customer reports an error or when an exception alert email lands. Pair it with rConfig API Logs if the issue is API-related.

rConfig API Logs

/admin/rconfig-api-logs is the per-request log of every Prism → rConfig API call: endpoint, method, response time, status, cache hit/miss flag. Searchable, filterable, exportable.

This is where you spot slow endpoints, frequent failures, or cache misses that ought to be hits.

Impersonation

When a customer reports a problem you can’t reproduce from your admin sidebar, impersonate them.

1. Open the user menu (sidebar → user avatar).
2. Click Impersonate user.
3. Search for the user (autocomplete searches name and email).
4. Click their row.

Prism swaps your session into theirs and redirects to the portal dashboard scoped to their team. An amber banner across the top shows You are impersonating {name} — Stop impersonating. Click the stop button to swap back. No password and no 2FA challenge are needed in either direction; both transitions are written to the impersonation audit.

You can’t impersonate while already impersonating. The dialog rejects attempts to chain.

A full operator runbook (start/stop, common pitfalls, audit retrieval queries) lives at /admin/docs/features/impersonation inside the running instance.

Operator Docs

/admin/docs is the in-app help center. Markdown content lives next to the running code, so it’s always version-locked to your install. Topics include detailed setup runbooks, security hardening checklists, exception alert tuning, audit retention recipes, brand setting cookbook, and per-feature deep dives.

The right place for an operator’s “how do I do X” question is usually here, not on this site. This Astro doc site is the public marketing-and-orientation surface; the in-app docs are the operations manual.

Onboarding

The onboarding checklist is documented in Getting Started. After initial setup, you can re-open the card from the sidebar’s Onboarding entry — useful when a new operator joins your team, or when you want to revisit a manual item like the security hardening review.

Three of the twelve tasks are manual ticks (queue manager check, system optimization review, security hardening). The rest are observable and self-complete the moment Prism detects you’ve done the underlying work.

When Things Go Wrong

The triage order is almost always:

1. Exception Logs — is there an open error matching the symptom?
2. rConfig API Logs — is the upstream healthy or returning errors?
3. Access Audit — is the user even reaching Prism?
4. System Optimization — is the host configured for production load?
5. /admin/docs/troubleshooting — version-specific runbooks.
6. Troubleshooting — public-facing symptom catalogue.
7. Support — open a ticket if you’re still stuck.

Related Documentation

• Getting Started — First-day setup walkthrough.
• Portal Guide — What your customers see.
• Key Features — Feature catalogue.
• Best Practices — Hardening, retention, branding, and operations advice.
• Troubleshooting — Common operational issues.
• Support — How to reach the rConfig support team.