Skip to main content
Preferences let each of your users decide which notifications they receive and on which channels. A preference is the link between one user and one notification type: it records whether that type is enabled for them and which channels to use. When a notification is sent, Archie looks at the recipient’s preference for that type:
  • No preference row yet? The type’s Default subscribed setting decides whether they receive it.
  • Preference exists and is enabled with at least one channel? They receive it on those channels.
  • Preference exists but is disabled? They are skipped — unless the type is Mandatory, which always reaches everyone.
Preferences are scoped per environment, like everything else in the Notifications module.

​
Anatomy of a preference

A user has at most one preference per type — the pair (user, type) is unique.

​
Configure from the Archie web app

Most teams expose preferences inside their own application’s “Notification settings” screen, but you can also manage them directly:
1

Open the Preferences tab

Navigate to App Services → Notifications and open the Preferences tab.
2

Find a user

Search for a user, then click + Add Preference (or edit an existing row).
3

Configure the preference

Choose the Notification type, toggle Enabled, and select the Channels.
4

Save

Click Save.

​
Configure through the GraphQL API

Preferences are a standard table, available through the auto-generated GraphQL operations on your project endpoint (https://archie-core.services.archie.com/graphql) with the X-Project-Id, X-Environment, and Authorization headers.

​
Set (or update) a user’s preference

The most common pattern is “create it if missing, update it if present.” You can do that with a single upsert-style call keyed on (user, type):
To change channels or turn a type off later:

​
Read a user’s preferences

Soft-deleted records. List queries exclude soft-deleted rows by default. To include preferences that have been soft-deleted, pass the withDeleted: true argument on the list query (e.g., archieUserNotificationPreferences(withDeleted: true) { items { id } }). Omit it — or set it to false — to return only active rows.

​
Build a “notification settings” screen

A typical settings page combines the two tables:
  1. Read the catalog of active, user-configurable types (archieNotificationTypes where isActive = true and canBeDisabled = true).
  2. Read the user’s existing preferences.
  3. For each type, show a toggle and channel pickers, pre-filled from the preference (or from the type’s defaults when the user has no row yet).
  4. On save, create or update the matching preference.
Mandatory types (isMandatory = true) should be shown as read-only — the user always receives them, so don’t offer an off switch.

​
Next step

With your catalog and preferences in place, you’re ready to send notifications.