Notifications Builder
Editable in-app and email notification definitions, templates, delivery rules and delivery history.
/admin/settings/notificationsFuture Spec 03 →Current-state summary
Notifications Builder contains an Event catalogue, Templates, Delivery rules and Delivery history. It registers 28 events focused on Workspace invitation, Applications, provisioning and Provider onboarding. The invitation template supports draft/publish versions, subject variables, brand tokens and design/preview modes. Delivery rules cover in-app and email recipients/timing; no SMS catalogue is visible. Delivery history is provider-neutral and currently empty.
Interface inventory
Anatomy and verified behavior
Verification states separate observed behavior from requirements or assumptions.
| Element | Current behavior | Verification |
|---|---|---|
| Event catalogue | 28 stable keys, heavily concentrated in Application and provisioning domains. | Verified live |
| Template builder | Invitation subject, variables, branding tokens, preview, save draft and publish version. | Verified live without saving |
| Delivery rules | Event recipient, Workspace Owners or Workspace Administrators; in-app/email timing and enabled/required controls. | Verified live |
| Delivery history | Provider-neutral audit promises template, provider, state, timestamps and failure outcome; no attempts exist. | Verified empty state |
User journeys
Current flows
Publish notification
- Register Domain Event and variables
- Author channel template
- Preview with safe sample data
- Configure recipient and timing rule
- Publish immutable version
- Trigger event
- Observe provider delivery and retries
State model
Current and expected states
Save draft supported.
Publish action supported.
Both control patterns exist.
Promised in audit; no live attempts.
Product rules
Non-negotiable boundaries
- Features register events; templates do not invent business events.
- Published templates are immutable.
- Recipient calculation is permission-aware and explainable.
- Provider delivery is idempotent and retry-safe.
- Resend is the initial email provider but provider-neutral delivery records remain canonical.
- SMS requires consent and Twilio channel governance.
Known current limitations · 4 mapped
What is missing, broken or unverified
Future Spec 03 owns closure →- No Project, Task, Offer, commercial, receiving, delivery, approval, communication, security or integration events are registered.
- No SMS templates/rules are visible.
- No real delivery history exists.
- Template localization and accessibility checks are not evidenced.
Future alignment
Required evolution
- 01Expand to the cross-product event matrix in every future spec.
- 02Add User and Workspace preferences, quiet hours, digesting and escalation.
- 03Connect Resend webhooks, retry state and suppression handling.
- 04Add SMS only with consent and compliant sender configuration.
Current baseline
Acceptance record
- Every new feature defines required notification events.
- No event is considered complete without variables, recipients, channels and delivery semantics.
- Delivery audit never depends solely on provider logs.
- Cross-product coverage is tracked explicitly.
Reverse-spec completeness
Documentation coverage
The interface is still changing, so visual evidence and repository tracing remain intentionally incomplete.
Purpose and user outcome
DocumentedRoles and access
DocumentedRoutes and entry points
DocumentedPage and component anatomy
DocumentedFields and displayed data
DocumentedPrimary actions
DocumentedForms and validation
DocumentedStates and transitions
DocumentedEmpty, loading and error states
DocumentedResponsive behavior
PartialAccessibility behavior
PartialActivity and audit events
PartialData sources and persistence
DocumentedNotifications and automation
PartialKnown defects and limitations
DocumentedReusable component dependencies
DocumentedFuture-spec conflicts
PartialVisual and repository evidence
DeferredAcceptance of current baseline
Documented