Preferences

Notification preferences are per-user, auto-created on first access, and live at Settings → Notifications in the user profile. Changes take effect immediately.

The goal is simple: let every user decide what rises to their attention and what gets filtered out. The default settings work for most people; the knobs exist for the rest.

Source toggles

Each of the eight notification sources has its own on/off toggle. All are on by default:

Turn a source off and Fabrik silently drops notifications from that source for you — no in-app entry, no email, no digest. The create_notification() call in the backend returns None and moves on.

Delivery channels

Two channels, independently toggleable:

In-app

• in_app_enabled — default on.
• Covers the bell dropdown, the notification center, the WebSocket push, and the toasts.
• Turning this off silences everything in-app; even explicitly-sent notifications won't be stored.

This is the master switch for the in-app experience. Few users touch it — you almost always want the bell to keep working — but it exists for service accounts or users who only care about email.

Email

• email_enabled — default off.
• Requires NOTIFICATION_EMAIL_ENABLED=true in the server config (admin-managed).
• Requires the user to have a valid email address on file.
• Subject to the severity threshold (see below).

Email delivery is opt-in on both sides — the admin has to enable it at the deployment level, and each user has to turn it on for themselves. This keeps email quiet by default; no accidental flooding of inboxes when Fabrik is first installed.

Severity threshold for email

email_min_severity — default warning. Only notifications at or above this severity send email:

• info — everything emails (rarely useful).
• success — success + warning + error.
• warning — warning + error (default).
• error — only errors.

The threshold gates only email. In-app delivery ignores it; the center shows every notification regardless of severity.

This is the single most useful knob. Raise to error and your inbox only hears from Fabrik when something has actually broken.

Quiet hours

Two fields plus a master toggle:

• quiet_hours_enabled — default off.
• quiet_hours_start / quiet_hours_end — time-of-day, local timezone.

When enabled, any notification created during the window is dropped silently — no in-app entry, no email, no buffering for later. The backend returns early and nothing is persisted for you specifically (the event still exists for other users).

The window can cross midnight: 22:00 → 07:00 means "from 10pm until 7am next morning." The backend detects this case and treats it as an overnight range.

Typical uses:

• Personal do-not-disturb. 22:00 → 07:00 for overnight hours.
• On-call rotation handoff. Quiet hours during someone else's on-call window.
• Weekend peace. Currently no day-of-week filter; quiet hours apply every day. A workaround is to simply disable sources on Friday and re-enable Monday.

Quiet hours always use your local timezone (from your user profile). A 22:00 → 07:00 window for a user in Istanbul fires at 22:00 Istanbul time regardless of where the server is.

Timezone awareness

Notification timestamps in the UI are rendered in your local timezone. The underlying record is UTC; the rendering uses the user's configured timezone to show when it happened for you.

This matters most for:

• Scheduled tasks that fire at specific wall-clock times (which are in the task's timezone, not yours).
• Quiet hours which are enforced using your local time.
• Heatmap-style correlation across users in different regions.

If your notifications arrive at "wrong" times, the first thing to check is your user timezone.

When a notification is dropped

Summary of the drop chain — the first reason to fire suppresses everything after it:

1. Per-source toggle is off.
2. in_app_enabled is off.
3. digest_enabled is on (notification is buffered, not dropped — see next page).
4. Quiet hours are active.

After all four checks pass, the notification is persisted and either pushed via WebSocket or stored for the next refresh.

Reading and clearing

Three ways to mark as read:

• Click the notification in the dropdown or center.
• Mark all read in the dropdown.
• Bulk mark read by filter in the center.

Marking read is atomic: is_read=true, read_at=<now>. The read state doesn't affect deletion — cleanup rules apply regardless — but the retention policy is longer for unread.

Deleting

The center lets you delete individual notifications or bulk-delete by filter. This is the right tool for "I don't want this in my history" — it removes the row entirely. Cleanup will remove old ones anyway; manual delete is for explicit curation.

There is no restore. Deleted notifications are gone.

Metadata and deep links

The metadata JSON on each notification is where source-specific context lives:

• {"source": "scheduled_task_failure", "connection_id": "...", "connection_name": "APIC-EAST"}
• {"source": "awx_execution_failure", "execution_id": "...", "job_id": 4821}
• {"source": "connection_health", "last_tested": "..."}

The frontend uses these keys to render context badges next to the message and to build deep links. Escalation-flagged notifications also set {"escalated_from": "<uuid>", "original_user": "..."} — see the next page.

You don't interact with metadata directly from the UI; it's read-only display context.

Troubleshooting

---

Preferences control what you see and when. The next page — Digest and escalation — is about batching and automatic re-routing: collapsing noisy streams into summaries and making sure critical notifications can't be ignored.