What granularity controls
Granularity declares how finely account users can control notifications for this event in Settings → Notifications (especially Web Push, which is per-user and opt-in).
It does not split shared Email or SMS recipient lists on this admin row — those stay one list per event code for the whole account.
App-level
One preference covers every notification event published by the application (wildcard at the app scope). Use when a single on/off for the whole app is enough — for example early rollouts where each app exposes one business event.
Example: “Notify me for anything from Shopping Cart” without separate toggles per event code.
Per event type
Users choose separately for each event code on this catalog (e.g. new-order vs new-registration). This is the default choice for most customer-originated events.
Example: Almotawif new-reservation — staff can enable push for new reservations without enabling every other mt event.
Per entity
Users opt in to specific records within the same event type. The firing code must send an entity id (form id, campaign id, etc.) and the user settings UI must let them pick which entities matter.
Example: Content management (cm) form submissions — one event code such as form-submitted, many forms; a user enables push only for selected forms (contact, volunteer, etc.), not every form on the site.
Not a fit: one-off transactions like a single new reservation or order — there is no stable list of entities to subscribe to. Use Per event type instead.
Choosing a value
- Most catalog rows → Per event type.
- Legacy/simple single-event apps → App-level is acceptable.
- Only use Per entity when the app will ship entity pickers and hooks that pass
EntityIdat dispatch time.