Notification and Portal Surface Service designed
Notifications and documentation publication are both platform surfaces. Products can contribute content and events, but they should not fork delivery rules, template ownership, or publication tracks.
Shared-Service Boundary
| Capability | Owned here |
|---|---|
| Notification templates | stable template IDs, variables, severity, default channels |
| Delivery intent | audience, scope, dedupe, correlation, eligible channels |
| Policy/preference interaction | suppression rules, tenant narrowing, critical-notice rules |
| Portal publication tracks | internal, customer, partner, public visibility metadata and review posture |
Delivery Intent Model
Products should emit delivery intent, not raw email bodies.
Core fields:
- template ID and version;
- owner product;
- event or evidence reference;
- audience and scope;
- severity;
- candidate channels;
- dedupe key;
- correlation ID.
Publication Tracks
| Track | Typical reader | Default posture |
|---|---|---|
| Internal | product, architecture, ops, security, developers | rich technical detail allowed |
| Customer | tenant admin, customer reviewer | redacted, curated, customer-safe |
| Partner | SDK/app integrators | contract-focused, implementation-safe |
| Public | broad external readers | minimal, intentionally filtered |
Why This Matters
The portal itself is a shared-service output. If publication rules are implicit, the team either over-exposes internals or under-documents the system.
That is the same problem notification systems have: if template and audience rules are local to each product surface, the platform becomes inconsistent and unsafe.
Design Rules
- Critical notices cannot be silently bypassed by product code.
- Tenant customization narrows but does not override hard security rules.
- Publication class is metadata-driven, not folder-layout driven.
- Internal source docs are not automatically customer-safe docs.