Three related setup areas: how PulseServe notifies people, how it pages the on-call rotation, and how your organization's identity provider handles login.
Notifications
Settings → Notifications covers five channels independently:
- Slack — webhook URL, signing secret, and bot token, with a Test Webhook button and toggles for SLA breach, AI pipeline review, and assignment notifications.
- Microsoft Teams — its own webhook URL and Test Webhook button.
- Email — toggles per event (breach, assignment, pipeline review, request status change, resolved, closed) plus a notification-from address.
- Push notifications — toggles for assignment, manager approval, workflow approval, technical review, CAB review, knowledge-review-due, and watcher updates.
- SMTP server — host, port, TLS, credentials, and a from-address, with the option to fall back to environment-configured SMTP instead of filling this in.
Working from Slack
The same Slack connection also powers a real interactive bot, not just outbound notifications. Typing /pulseserve followed by a title in any connected Slack channel creates an incident directly (it checks for a matching open one first, so a repeated command doesn't create duplicates) and posts back a message with Assign to Me and Acknowledge buttons right in Slack — clicking one updates the incident and refreshes the Slack message to show who acted, matched by the Slack user's email against a PulseServe account.
On-call paging
Settings → People & Access → On-Call Paging is where the paging provider itself is set up — PagerDuty, Opsgenie, or a generic webhook, each with its own credential fields — plus the escalation timeout, max attempts, which channels (Slack/email/push) get used, and a fallback schedule/target for when the whole primary chain goes unanswered. Schedules, rotations, and overrides themselves are managed separately — see SLA & On-Call.
Single sign-on
Admin → SSO lets you connect an identity provider so your team signs in with existing corporate credentials instead of a PulseServe-specific password. Turn it on, pick SAML or OIDC, and fill in the provider-specific fields:
- SAML — your identity provider's SSO URL, your service-provider entity ID, and the IdP's certificate. PulseServe shows you its own ACS URL and metadata URL (with copy buttons) to paste back into your identity provider's configuration.
- OIDC — issuer URL, client ID, and client secret. PulseServe shows you its redirect URI to paste into your provider.
API keys for machine ingest
Admin → API Keys is not a general-purpose API access page — it's specifically for authenticating external systems pushing data in: Alertmanager webhooks, a generic webhook source, inbound email, and software-inventory feeds. The page lists each endpoint's URL with a copy button; issue a named key, copy the raw value shown once, and paste both into the sending tool's configuration. Revoke a key at any time from the same list.
Example
An admin connects the company's Okta as the identity provider: enable SSO, choose SAML, paste in Okta's SSO URL and certificate, then copy PulseServe's ACS URL and metadata URL into Okta's application configuration. From then on, team members sign in through Okta instead of a separate PulseServe password.