Administration·9 min read

System, Security & Data Management

Branding, login security, retention, background jobs, and moving data in or out of the platform.

The remaining Settings → System and Settings → People & Access panels: everything about how the platform looks, how login is secured, how long data sticks around, and how to get data in or out wholesale.

Branding & localization

Set your organization name, logo, primary color, support email, and favicon under Branding — this applies across the main app and the self-service portal. Localization sets a default language and which of the supported languages (English, Spanish, French, German, Portuguese, Hindi, Chinese, Japanese, Arabic) show up as options on the login screen.

Login security

Password policy — minimum length and which character classes are required, enforced on registration, self-service reset, and admin-created accounts alike.
Two-factor authentication — a tenant-wide toggle to require it, with a grace-period so existing users aren't locked out immediately.
SMS provider — Twilio, Vonage, or a generic webhook, currently used to deliver 2FA codes.

Feature flags

A short list of optional features (guidance chat, the portal designer, the model builder) that can be switched on or off tenant-wide.

Data retention & archival

Data Retention lets you set, per record type (incidents, problems, changes, releases, service requests), how long closed records are kept before they're purged — Preview shows exactly how many rows would be affected before you commit, and the purge itself requires typing an exact confirmation phrase. Incident Archival is a softer, separate mechanism: it moves old closed incidents into an archive table to keep the live list fast, rather than deleting them.

License & platform access

Enter and activate your license key from the top of Settings — it's verified live against the license server and re-checked daily. For an air-gapped deployment, an offline activation flow lets you copy your instance's machine fingerprint, send it to get a signed activation blob, and paste that back in instead. Platform Access controls whether this instance accepts calls from the vendor control plane at all (for things like suspend/reactivate or support impersonation).

Disaster recovery

A dedicated Activate/Deactivate control for declaring your organization is in a disaster-recovery posture — optionally auto-declaring a major incident when activated, so the same commander/bridge/stakeholder-update tooling from Cascade Detection & Major Incidents kicks in immediately rather than someone having to set it up by hand mid-crisis.

Platform Watchdog — background jobs and self-healing checks

PulseServe runs dozens of background jobs behind the scenes — sweeps for SLA breaches, escalations, predictive scans, sync polling, and more. Admin → Platform Watchdog is the single dashboard for all of it: stat cards for stuck incidents/changes/problems/workflows, license status, database load, whether every connected MELT source is still reporting, and a live table of every background job with its last run time, duration, status, and how many times it's failed in the last 24 hours.

Two actions are available per job: Enable/Disable (a kill switch for a misbehaving job, no redeploy needed) and Run Now (trigger it immediately instead of waiting for its next scheduled tick — useful right after fixing whatever was causing it to fail). Both ask for confirmation before acting.

This is where the platform "self-heals" in a visible way: if a background job fails continuously for over an hour, PulseServe automatically raises an alert (the same alert pipeline documented on the Alerts page) rather than failing silently — and that alert clears itself automatically the next time the job succeeds. You don't have to watch this dashboard around the clock for it to catch a stuck job; it comes looking for you when something's actually wrong for long enough to matter.

The same page also surfaces the health of your ServiceNow/Jira integration connections and your notification channels (Slack, Teams, email) — each with its own last-error and consecutive-failure tracking, so a silently broken webhook or an expired credential shows up here instead of just going quiet.

Settings recovery

Every settings namespace keeps its own change history. Pick one under Settings Recovery and click View History for timestamped snapshots, Undo Last Change to revert the most recent save, or Export All Settings / Import Settings to move the full configuration as a JSON file — useful before a risky change, or to replicate settings across tenants.

Importing data

Data Import is meant for onboarding a new client, not routine entry — CSV upload for Users, Incidents, Problems, or Knowledge (and, separately, CIs from the CMDB page), each with its own required/optional column list shown right in the UI. If a client's spreadsheet uses its own vocabulary for things like priority or urgency — "Sev1" instead of "critical," say — a value-mapping table translates those into PulseServe's own values automatically during import, so you don't have to hand-edit the source file first.

Data Export & Offboarding downloads — or permanently deletes — this instance's business data (incidents, problems, changes, releases, service requests, the full CMDB, knowledge articles) for a contract end or a right-to-erasure request. It does not touch user accounts or settings. The delete path is confirmation-gated: Preview shows exact row counts first, and the purge itself only unlocks after typing an exact confirmation phrase. Treat this as irreversible.

Example

A customer's contract ends. An admin uses Data Export & Offboarding to download a full JSON export of their incidents, changes, and CMDB for their own records, then previews the purge to see exactly how many rows will be removed, types the confirmation phrase, and permanently deletes the tenant's business data — while user accounts and settings, which the tool deliberately leaves untouched, are handled separately.