docs(configure): say which channels render a Notification Template#247

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
os-bill merged 1 commit into from
Sep 2, 2026
Merged

docs(configure): say which channels render a Notification Template #247

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 26 additions & 6 deletions content/docs/configure/notifications.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -25,8 +25,10 @@ emit() + explicit audience → Notification Event → recipients, filtered b
read it.
3. **Routing** — For each event, ObjectOS expands the audience the producer
passed into recipients, checks whether each recipient allows that topic on
that channel (**Preferences**), and renders the message for the recipient's
channel and locale (**Templates**).
that channel (**Preferences**), and hands each accepted delivery to its
channel, which renders it. What a channel renders *from* differs by channel:
email and SMS render **Notification Templates**; the in-app inbox does not
(see [What each channel renders](#what-each-channel-renders)).
4. **Inbox Message** (`sys_inbox_message`) — The materialized, per-user result
the recipient actually sees in their inbox.

Expand All@@ -41,7 +43,7 @@ For a single event, these are the inputs that decide who gets what:
|---|---|
| The audience passed to `emit()` | *Who receives this?* — the producer names the recipients, and this is the only input that puts anyone on the list |
| Notification Preference | *Does this recipient allow it here?* — the per-user mute/allow for the topic and channel, applied to every (recipient × channel) pair |
| Notification Template | *How is it written?* — the subject and body to render for the recipient's channel and locale |
| Notification Template | *How is it written?* — the subject and body rendered on the **email** and **SMS** channels. The in-app inbox does not read these rows; see [What each channel renders](#what-each-channel-renders) |
| Notification Subscription | *Who declared standing interest?* — admin-authored rows, **not consulted when an event is routed** |

A recipient reaches the inbox when the producer's audience resolves to them and
Expand DownExpand Up@@ -154,9 +156,10 @@ value first.

At **Setup → Configuration → Notification Templates** (`sys_notification_template`).

A per **(topic × channel × locale)** render template. Templates turn an event
payload into the subject and body a recipient reads, in their locale and for
their channel.
A per **(topic × channel × locale)** render template, read by the **email** and
**SMS** channels: a template turns an event payload into the subject and body
those channels send. The in-app inbox does not read these rows — see
[What each channel renders](#what-each-channel-renders).

| Field | Purpose |
|---|---|
Expand All@@ -174,6 +177,23 @@ capabilities you run, so most of your work is editing template content or
toggling `is_active`, `enabled`, and preference defaults rather than creating
records from scratch.

### What each channel renders

Rendering happens per channel, and only two channels read the rows above:

| Channel | Renders from |
|---|---|
| **Email** | The Notification Template matching (topic, `email`, locale). With no matching active row, the notification's own title and body are sent as-is |
| **SMS** | The Notification Template matching (topic, `sms`, locale), with the same fallback |
| **In-app inbox** | **Not a Notification Template.** The inbox row is written from the notification's own title and body — the topic, when the producer set no title. When the notification names an email template instead, the inbox renders that one: a `sys_email_template` row resolved by (name, locale) through the email service, which [Email](/docs/configure/email#templates) documents. Without an email service able to render it, that delivery fails rather than falling back |

> **Warning:** `inbox` is the **default** channel — a notification that names no
> channels is delivered there and nowhere else. So the delivery an admin is
> most likely looking at is the one that never reads a Notification Template:
> editing a template row here changes what email and SMS send, and changes
> nothing about the in-app message. This page describes the wiring as it
> stands; it does not forecast an inbox seam to these rows.

## Where to go next

| Task | Page |
Expand Down
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
docs(configure): say which channels render a Notification Template#247

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

os-bill
merged 1 commit into

from

Sep 2, 2026
 Merged


docs(configure): say which channels render a Notification Template
#247
 Changes from all commits
Commits

Show all changes


1 commit


Select commit


File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


32 changes: 26 additions & 6 deletions
content/docs/configure/notifications.mdx

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -25,8 +25,10 @@ emit() + explicit audience → Notification Event → recipients, filtered b
 read it.
3. **Routing** — For each event, ObjectOS expands the audience the producer
 passed into recipients, checks whether each recipient allows that topic on
 that channel (**Preferences**), and renders the message for the recipient's
 channel and locale (**Templates**).
 that channel (**Preferences**), and hands each accepted delivery to its
 channel, which renders it. What a channel renders *from* differs by channel:
 email and SMS render **Notification Templates**; the in-app inbox does not
 (see [What each channel renders](#what-each-channel-renders)).
4. **Inbox Message** (`sys_inbox_message`) — The materialized, per-user result
 the recipient actually sees in their inbox.

Expand All@@ -41,7 +43,7 @@ For a single event, these are the inputs that decide who gets what:
|---|---|
| The audience passed to `emit()` | *Who receives this?* — the producer names the recipients, and this is the only input that puts anyone on the list |
| Notification Preference | *Does this recipient allow it here?* — the per-user mute/allow for the topic and channel, applied to every (recipient × channel) pair |
| Notification Template | *How is it written?* — the subject and body to render for the recipient's channel and locale |
| Notification Template | *How is it written?* — the subject and body rendered on the **email** and **SMS** channels. The in-app inbox does not read these rows; see [What each channel renders](#what-each-channel-renders) |
| Notification Subscription | *Who declared standing interest?* — admin-authored rows, **not consulted when an event is routed** |

A recipient reaches the inbox when the producer's audience resolves to them and
Expand DownExpand Up@@ -154,9 +156,10 @@ value first.

At **Setup → Configuration → Notification Templates** (`sys_notification_template`).

A per **(topic × channel × locale)** render template. Templates turn an event
payload into the subject and body a recipient reads, in their locale and for
their channel.
A per **(topic × channel × locale)** render template, read by the **email** and
**SMS** channels: a template turns an event payload into the subject and body
those channels send. The in-app inbox does not read these rows — see
[What each channel renders](#what-each-channel-renders).

| Field | Purpose |
|---|---|
Expand All@@ -174,6 +177,23 @@ capabilities you run, so most of your work is editing template content or
toggling `is_active`, `enabled`, and preference defaults rather than creating
records from scratch.

### What each channel renders

Rendering happens per channel, and only two channels read the rows above:

| Channel | Renders from |
|---|---|
| **Email** | The Notification Template matching (topic, `email`, locale). With no matching active row, the notification's own title and body are sent as-is |
| **SMS** | The Notification Template matching (topic, `sms`, locale), with the same fallback |
| **In-app inbox** | **Not a Notification Template.** The inbox row is written from the notification's own title and body — the topic, when the producer set no title. When the notification names an email template instead, the inbox renders that one: a `sys_email_template` row resolved by (name, locale) through the email service, which [Email](/docs/configure/email#templates) documents. Without an email service able to render it, that delivery fails rather than falling back |

> **Warning:** `inbox` is the **default** channel — a notification that names no
> channels is delivered there and nowhere else. So the delivery an admin is
> most likely looking at is the one that never reads a Notification Template:
> editing a template row here changes what email and SMS send, and changes
> nothing about the in-app message. This page describes the wiring as it
> stands; it does not forecast an inbox seam to these rows.

## Where to go next

| Task | Page |
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
docs(configure): say which channels render a Notification Template#247

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

os-bill
merged 1 commit into

from

Sep 2, 2026
 Merged


docs(configure): say which channels render a Notification Template
#247
 Changes from all commits
Commits

Show all changes


1 commit


Select commit


File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


32 changes: 26 additions & 6 deletions
content/docs/configure/notifications.mdx

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -25,8 +25,10 @@ emit() + explicit audience → Notification Event → recipients, filtered b
 read it.
3. **Routing** — For each event, ObjectOS expands the audience the producer
 passed into recipients, checks whether each recipient allows that topic on
 that channel (**Preferences**), and renders the message for the recipient's
 channel and locale (**Templates**).
 that channel (**Preferences**), and hands each accepted delivery to its
 channel, which renders it. What a channel renders *from* differs by channel:
 email and SMS render **Notification Templates**; the in-app inbox does not
 (see [What each channel renders](#what-each-channel-renders)).
4. **Inbox Message** (`sys_inbox_message`) — The materialized, per-user result
 the recipient actually sees in their inbox.

Expand All@@ -41,7 +43,7 @@ For a single event, these are the inputs that decide who gets what:
|---|---|
| The audience passed to `emit()` | *Who receives this?* — the producer names the recipients, and this is the only input that puts anyone on the list |
| Notification Preference | *Does this recipient allow it here?* — the per-user mute/allow for the topic and channel, applied to every (recipient × channel) pair |
| Notification Template | *How is it written?* — the subject and body to render for the recipient's channel and locale |
| Notification Template | *How is it written?* — the subject and body rendered on the **email** and **SMS** channels. The in-app inbox does not read these rows; see [What each channel renders](#what-each-channel-renders) |
| Notification Subscription | *Who declared standing interest?* — admin-authored rows, **not consulted when an event is routed** |

A recipient reaches the inbox when the producer's audience resolves to them and
Expand DownExpand Up@@ -154,9 +156,10 @@ value first.

At **Setup → Configuration → Notification Templates** (`sys_notification_template`).

A per **(topic × channel × locale)** render template. Templates turn an event
payload into the subject and body a recipient reads, in their locale and for
their channel.
A per **(topic × channel × locale)** render template, read by the **email** and
**SMS** channels: a template turns an event payload into the subject and body
those channels send. The in-app inbox does not read these rows — see
[What each channel renders](#what-each-channel-renders).

| Field | Purpose |
|---|---|
Expand All@@ -174,6 +177,23 @@ capabilities you run, so most of your work is editing template content or
toggling `is_active`, `enabled`, and preference defaults rather than creating
records from scratch.

### What each channel renders

Rendering happens per channel, and only two channels read the rows above:

| Channel | Renders from |
|---|---|
| **Email** | The Notification Template matching (topic, `email`, locale). With no matching active row, the notification's own title and body are sent as-is |
| **SMS** | The Notification Template matching (topic, `sms`, locale), with the same fallback |
| **In-app inbox** | **Not a Notification Template.** The inbox row is written from the notification's own title and body — the topic, when the producer set no title. When the notification names an email template instead, the inbox renders that one: a `sys_email_template` row resolved by (name, locale) through the email service, which [Email](/docs/configure/email#templates) documents. Without an email service able to render it, that delivery fails rather than falling back |

> **Warning:** `inbox` is the **default** channel — a notification that names no
> channels is delivered there and nowhere else. So the delivery an admin is
> most likely looking at is the one that never reads a Notification Template:
> editing a template row here changes what email and SMS send, and changes
> nothing about the in-app message. This page describes the wiring as it
> stands; it does not forecast an inbox seam to these rows.

## Where to go next

| Task | Page |
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
docs(configure): say which channels render a Notification Template#247

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

os-bill
merged 1 commit into

from

Sep 2, 2026
 Merged


docs(configure): say which channels render a Notification Template
#247
 Changes from all commits
Commits

Show all changes


1 commit


Select commit


File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


32 changes: 26 additions & 6 deletions
content/docs/configure/notifications.mdx

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -25,8 +25,10 @@ emit() + explicit audience → Notification Event → recipients, filtered b
 read it.
3. **Routing** — For each event, ObjectOS expands the audience the producer
 passed into recipients, checks whether each recipient allows that topic on
 that channel (**Preferences**), and renders the message for the recipient's
 channel and locale (**Templates**).
 that channel (**Preferences**), and hands each accepted delivery to its
 channel, which renders it. What a channel renders *from* differs by channel:
 email and SMS render **Notification Templates**; the in-app inbox does not
 (see [What each channel renders](#what-each-channel-renders)).
4. **Inbox Message** (`sys_inbox_message`) — The materialized, per-user result
 the recipient actually sees in their inbox.

Expand All@@ -41,7 +43,7 @@ For a single event, these are the inputs that decide who gets what:
|---|---|
| The audience passed to `emit()` | *Who receives this?* — the producer names the recipients, and this is the only input that puts anyone on the list |
| Notification Preference | *Does this recipient allow it here?* — the per-user mute/allow for the topic and channel, applied to every (recipient × channel) pair |
| Notification Template | *How is it written?* — the subject and body to render for the recipient's channel and locale |
| Notification Template | *How is it written?* — the subject and body rendered on the **email** and **SMS** channels. The in-app inbox does not read these rows; see [What each channel renders](#what-each-channel-renders) |
| Notification Subscription | *Who declared standing interest?* — admin-authored rows, **not consulted when an event is routed** |

A recipient reaches the inbox when the producer's audience resolves to them and
Expand DownExpand Up@@ -154,9 +156,10 @@ value first.

At **Setup → Configuration → Notification Templates** (`sys_notification_template`).

A per **(topic × channel × locale)** render template. Templates turn an event
payload into the subject and body a recipient reads, in their locale and for
their channel.
A per **(topic × channel × locale)** render template, read by the **email** and
**SMS** channels: a template turns an event payload into the subject and body
those channels send. The in-app inbox does not read these rows — see
[What each channel renders](#what-each-channel-renders).

| Field | Purpose |
|---|---|
Expand All@@ -174,6 +177,23 @@ capabilities you run, so most of your work is editing template content or
toggling `is_active`, `enabled`, and preference defaults rather than creating
records from scratch.

### What each channel renders

Rendering happens per channel, and only two channels read the rows above:

| Channel | Renders from |
|---|---|
| **Email** | The Notification Template matching (topic, `email`, locale). With no matching active row, the notification's own title and body are sent as-is |
| **SMS** | The Notification Template matching (topic, `sms`, locale), with the same fallback |
| **In-app inbox** | **Not a Notification Template.** The inbox row is written from the notification's own title and body — the topic, when the producer set no title. When the notification names an email template instead, the inbox renders that one: a `sys_email_template` row resolved by (name, locale) through the email service, which [Email](/docs/configure/email#templates) documents. Without an email service able to render it, that delivery fails rather than falling back |

> **Warning:** `inbox` is the **default** channel — a notification that names no
> channels is delivered there and nowhere else. So the delivery an admin is
> most likely looking at is the one that never reads a Notification Template:
> editing a template row here changes what email and SMS send, and changes
> nothing about the in-app message. This page describes the wiring as it
> stands; it does not forecast an inbox seam to these rows.

## Where to go next

| Task | Page |
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
docs(configure): say which channels render a Notification Template#247

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

os-bill
merged 1 commit into

from

Sep 2, 2026
 Merged


docs(configure): say which channels render a Notification Template
#247
 Changes from all commits
Commits

Show all changes


1 commit


Select commit


File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


32 changes: 26 additions & 6 deletions
content/docs/configure/notifications.mdx

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -25,8 +25,10 @@ emit() + explicit audience → Notification Event → recipients, filtered b
 read it.
3. **Routing** — For each event, ObjectOS expands the audience the producer
 passed into recipients, checks whether each recipient allows that topic on
 that channel (**Preferences**), and renders the message for the recipient's
 channel and locale (**Templates**).
 that channel (**Preferences**), and hands each accepted delivery to its
 channel, which renders it. What a channel renders *from* differs by channel:
 email and SMS render **Notification Templates**; the in-app inbox does not
 (see [What each channel renders](#what-each-channel-renders)).
4. **Inbox Message** (`sys_inbox_message`) — The materialized, per-user result
 the recipient actually sees in their inbox.

Expand All@@ -41,7 +43,7 @@ For a single event, these are the inputs that decide who gets what:
|---|---|
| The audience passed to `emit()` | *Who receives this?* — the producer names the recipients, and this is the only input that puts anyone on the list |
| Notification Preference | *Does this recipient allow it here?* — the per-user mute/allow for the topic and channel, applied to every (recipient × channel) pair |
| Notification Template | *How is it written?* — the subject and body to render for the recipient's channel and locale |
| Notification Template | *How is it written?* — the subject and body rendered on the **email** and **SMS** channels. The in-app inbox does not read these rows; see [What each channel renders](#what-each-channel-renders) |
| Notification Subscription | *Who declared standing interest?* — admin-authored rows, **not consulted when an event is routed** |

A recipient reaches the inbox when the producer's audience resolves to them and
Expand DownExpand Up@@ -154,9 +156,10 @@ value first.

At **Setup → Configuration → Notification Templates** (`sys_notification_template`).

A per **(topic × channel × locale)** render template. Templates turn an event
payload into the subject and body a recipient reads, in their locale and for
their channel.
A per **(topic × channel × locale)** render template, read by the **email** and
**SMS** channels: a template turns an event payload into the subject and body
those channels send. The in-app inbox does not read these rows — see
[What each channel renders](#what-each-channel-renders).

| Field | Purpose |
|---|---|
Expand All@@ -174,6 +177,23 @@ capabilities you run, so most of your work is editing template content or
toggling `is_active`, `enabled`, and preference defaults rather than creating
records from scratch.

### What each channel renders

Rendering happens per channel, and only two channels read the rows above:

| Channel | Renders from |
|---|---|
| **Email** | The Notification Template matching (topic, `email`, locale). With no matching active row, the notification's own title and body are sent as-is |
| **SMS** | The Notification Template matching (topic, `sms`, locale), with the same fallback |
| **In-app inbox** | **Not a Notification Template.** The inbox row is written from the notification's own title and body — the topic, when the producer set no title. When the notification names an email template instead, the inbox renders that one: a `sys_email_template` row resolved by (name, locale) through the email service, which [Email](/docs/configure/email#templates) documents. Without an email service able to render it, that delivery fails rather than falling back |

> **Warning:** `inbox` is the **default** channel — a notification that names no
> channels is delivered there and nowhere else. So the delivery an admin is
> most likely looking at is the one that never reads a Notification Template:
> editing a template row here changes what email and SMS send, and changes
> nothing about the in-app message. This page describes the wiring as it
> stands; it does not forecast an inbox seam to these rows.

## Where to go next

| Task | Page |
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
docs(configure): say which channels render a Notification Template#247

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

os-bill
merged 1 commit into

from

Sep 2, 2026
 Merged


docs(configure): say which channels render a Notification Template
#247
 Changes from all commits
Commits

Show all changes


1 commit


Select commit


File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


32 changes: 26 additions & 6 deletions
content/docs/configure/notifications.mdx

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -25,8 +25,10 @@ emit() + explicit audience → Notification Event → recipients, filtered b
 read it.
3. **Routing** — For each event, ObjectOS expands the audience the producer
 passed into recipients, checks whether each recipient allows that topic on
 that channel (**Preferences**), and renders the message for the recipient's
 channel and locale (**Templates**).
 that channel (**Preferences**), and hands each accepted delivery to its
 channel, which renders it. What a channel renders *from* differs by channel:
 email and SMS render **Notification Templates**; the in-app inbox does not
 (see [What each channel renders](#what-each-channel-renders)).
4. **Inbox Message** (`sys_inbox_message`) — The materialized, per-user result
 the recipient actually sees in their inbox.

Expand All@@ -41,7 +43,7 @@ For a single event, these are the inputs that decide who gets what:
|---|---|
| The audience passed to `emit()` | *Who receives this?* — the producer names the recipients, and this is the only input that puts anyone on the list |
| Notification Preference | *Does this recipient allow it here?* — the per-user mute/allow for the topic and channel, applied to every (recipient × channel) pair |
| Notification Template | *How is it written?* — the subject and body to render for the recipient's channel and locale |
| Notification Template | *How is it written?* — the subject and body rendered on the **email** and **SMS** channels. The in-app inbox does not read these rows; see [What each channel renders](#what-each-channel-renders) |
| Notification Subscription | *Who declared standing interest?* — admin-authored rows, **not consulted when an event is routed** |

A recipient reaches the inbox when the producer's audience resolves to them and
Expand DownExpand Up@@ -154,9 +156,10 @@ value first.

At **Setup → Configuration → Notification Templates** (`sys_notification_template`).

A per **(topic × channel × locale)** render template. Templates turn an event
payload into the subject and body a recipient reads, in their locale and for
their channel.
A per **(topic × channel × locale)** render template, read by the **email** and
**SMS** channels: a template turns an event payload into the subject and body
those channels send. The in-app inbox does not read these rows — see
[What each channel renders](#what-each-channel-renders).

| Field | Purpose |
|---|---|
Expand All@@ -174,6 +177,23 @@ capabilities you run, so most of your work is editing template content or
toggling `is_active`, `enabled`, and preference defaults rather than creating
records from scratch.

### What each channel renders

Rendering happens per channel, and only two channels read the rows above:

| Channel | Renders from |
|---|---|
| **Email** | The Notification Template matching (topic, `email`, locale). With no matching active row, the notification's own title and body are sent as-is |
| **SMS** | The Notification Template matching (topic, `sms`, locale), with the same fallback |
| **In-app inbox** | **Not a Notification Template.** The inbox row is written from the notification's own title and body — the topic, when the producer set no title. When the notification names an email template instead, the inbox renders that one: a `sys_email_template` row resolved by (name, locale) through the email service, which [Email](/docs/configure/email#templates) documents. Without an email service able to render it, that delivery fails rather than falling back |

> **Warning:** `inbox` is the **default** channel — a notification that names no
> channels is delivered there and nowhere else. So the delivery an admin is
> most likely looking at is the one that never reads a Notification Template:
> editing a template row here changes what email and SMS send, and changes
> nothing about the in-app message. This page describes the wiring as it
> stands; it does not forecast an inbox seam to these rows.

## Where to go next

| Task | Page |
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
docs(configure): say which channels render a Notification Template#247

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

os-bill
merged 1 commit into

from

Sep 2, 2026
 Merged


docs(configure): say which channels render a Notification Template
#247
 Changes from all commits
Commits

Show all changes


1 commit


Select commit


File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


32 changes: 26 additions & 6 deletions
content/docs/configure/notifications.mdx

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -25,8 +25,10 @@ emit() + explicit audience → Notification Event → recipients, filtered b
 read it.
3. **Routing** — For each event, ObjectOS expands the audience the producer
 passed into recipients, checks whether each recipient allows that topic on
 that channel (**Preferences**), and renders the message for the recipient's
 channel and locale (**Templates**).
 that channel (**Preferences**), and hands each accepted delivery to its
 channel, which renders it. What a channel renders *from* differs by channel:
 email and SMS render **Notification Templates**; the in-app inbox does not
 (see [What each channel renders](#what-each-channel-renders)).
4. **Inbox Message** (`sys_inbox_message`) — The materialized, per-user result
 the recipient actually sees in their inbox.

Expand All@@ -41,7 +43,7 @@ For a single event, these are the inputs that decide who gets what:
|---|---|
| The audience passed to `emit()` | *Who receives this?* — the producer names the recipients, and this is the only input that puts anyone on the list |
| Notification Preference | *Does this recipient allow it here?* — the per-user mute/allow for the topic and channel, applied to every (recipient × channel) pair |
| Notification Template | *How is it written?* — the subject and body to render for the recipient's channel and locale |
| Notification Template | *How is it written?* — the subject and body rendered on the **email** and **SMS** channels. The in-app inbox does not read these rows; see [What each channel renders](#what-each-channel-renders) |
| Notification Subscription | *Who declared standing interest?* — admin-authored rows, **not consulted when an event is routed** |

A recipient reaches the inbox when the producer's audience resolves to them and
Expand DownExpand Up@@ -154,9 +156,10 @@ value first.

At **Setup → Configuration → Notification Templates** (`sys_notification_template`).

A per **(topic × channel × locale)** render template. Templates turn an event
payload into the subject and body a recipient reads, in their locale and for
their channel.
A per **(topic × channel × locale)** render template, read by the **email** and
**SMS** channels: a template turns an event payload into the subject and body
those channels send. The in-app inbox does not read these rows — see
[What each channel renders](#what-each-channel-renders).

| Field | Purpose |
|---|---|
Expand All@@ -174,6 +177,23 @@ capabilities you run, so most of your work is editing template content or
toggling `is_active`, `enabled`, and preference defaults rather than creating
records from scratch.

### What each channel renders

Rendering happens per channel, and only two channels read the rows above:

| Channel | Renders from |
|---|---|
| **Email** | The Notification Template matching (topic, `email`, locale). With no matching active row, the notification's own title and body are sent as-is |
| **SMS** | The Notification Template matching (topic, `sms`, locale), with the same fallback |
| **In-app inbox** | **Not a Notification Template.** The inbox row is written from the notification's own title and body — the topic, when the producer set no title. When the notification names an email template instead, the inbox renders that one: a `sys_email_template` row resolved by (name, locale) through the email service, which [Email](/docs/configure/email#templates) documents. Without an email service able to render it, that delivery fails rather than falling back |

> **Warning:** `inbox` is the **default** channel — a notification that names no
> channels is delivered there and nowhere else. So the delivery an admin is
> most likely looking at is the one that never reads a Notification Template:
> editing a template row here changes what email and SMS send, and changes
> nothing about the in-app message. This page describes the wiring as it
> stands; it does not forecast an inbox seam to these rows.

## Where to go next

| Task | Page |
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
docs(configure): say which channels render a Notification Template#247

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

os-bill
merged 1 commit into

from

Sep 2, 2026
 Merged


docs(configure): say which channels render a Notification Template
#247
 Changes from all commits
Commits

Show all changes


1 commit


Select commit


File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


32 changes: 26 additions & 6 deletions
content/docs/configure/notifications.mdx

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -25,8 +25,10 @@ emit() + explicit audience → Notification Event → recipients, filtered b
 read it.
3. **Routing** — For each event, ObjectOS expands the audience the producer
 passed into recipients, checks whether each recipient allows that topic on
 that channel (**Preferences**), and renders the message for the recipient's
 channel and locale (**Templates**).
 that channel (**Preferences**), and hands each accepted delivery to its
 channel, which renders it. What a channel renders *from* differs by channel:
 email and SMS render **Notification Templates**; the in-app inbox does not
 (see [What each channel renders](#what-each-channel-renders)).
4. **Inbox Message** (`sys_inbox_message`) — The materialized, per-user result
 the recipient actually sees in their inbox.

Expand All@@ -41,7 +43,7 @@ For a single event, these are the inputs that decide who gets what:
|---|---|
| The audience passed to `emit()` | *Who receives this?* — the producer names the recipients, and this is the only input that puts anyone on the list |
| Notification Preference | *Does this recipient allow it here?* — the per-user mute/allow for the topic and channel, applied to every (recipient × channel) pair |
| Notification Template | *How is it written?* — the subject and body to render for the recipient's channel and locale |
| Notification Template | *How is it written?* — the subject and body rendered on the **email** and **SMS** channels. The in-app inbox does not read these rows; see [What each channel renders](#what-each-channel-renders) |
| Notification Subscription | *Who declared standing interest?* — admin-authored rows, **not consulted when an event is routed** |

A recipient reaches the inbox when the producer's audience resolves to them and
Expand DownExpand Up@@ -154,9 +156,10 @@ value first.

At **Setup → Configuration → Notification Templates** (`sys_notification_template`).

A per **(topic × channel × locale)** render template. Templates turn an event
payload into the subject and body a recipient reads, in their locale and for
their channel.
A per **(topic × channel × locale)** render template, read by the **email** and
**SMS** channels: a template turns an event payload into the subject and body
those channels send. The in-app inbox does not read these rows — see
[What each channel renders](#what-each-channel-renders).

| Field | Purpose |
|---|---|
Expand All@@ -174,6 +177,23 @@ capabilities you run, so most of your work is editing template content or
toggling `is_active`, `enabled`, and preference defaults rather than creating
records from scratch.

### What each channel renders

Rendering happens per channel, and only two channels read the rows above:

| Channel | Renders from |
|---|---|
| **Email** | The Notification Template matching (topic, `email`, locale). With no matching active row, the notification's own title and body are sent as-is |
| **SMS** | The Notification Template matching (topic, `sms`, locale), with the same fallback |
| **In-app inbox** | **Not a Notification Template.** The inbox row is written from the notification's own title and body — the topic, when the producer set no title. When the notification names an email template instead, the inbox renders that one: a `sys_email_template` row resolved by (name, locale) through the email service, which [Email](/docs/configure/email#templates) documents. Without an email service able to render it, that delivery fails rather than falling back |

> **Warning:** `inbox` is the **default** channel — a notification that names no
> channels is delivered there and nowhere else. So the delivery an admin is
> most likely looking at is the one that never reads a Notification Template:
> editing a template row here changes what email and SMS send, and changes
> nothing about the in-app message. This page describes the wiring as it
> stands; it does not forecast an inbox seam to these rows.

## Where to go next

| Task | Page |
Expand Down