How do I let non-engineers edit notification templates and variables?

A good way to do this is to separate template content from template structure, then give non-engineers a controlled editor instead of raw code.

Recommended approach

1. Store templates in a template system, not in app code

Put notification templates in a database or CMS-like admin tool, not hardcoded in the repo. Each template should have:

• Name / purpose: password_reset, invoice_paid, etc.
• Channel: email, SMS, push, in-app
• Subject/body fields
• Allowed variables with descriptions
• Preview data for testing

This lets non-engineers edit content without redeploying.

---

2. Use placeholder variables with a safe syntax

Use a simple variable syntax such as:

• {{first_name}}
• {{order_number}}
• {{support_email}}

Avoid allowing arbitrary logic in templates if you want non-engineers to manage them safely.

A good rule: templates should support inserting variables, not programming.

---

3. Maintain a variable schema

Define each notification’s variables in a schema so the editor knows what’s available.

Example:

{
  "template_key": "invoice_paid",
  "variables": [
    {
      "name": "customer_name",
      "type": "string",
      "description": "The customer’s full name"
    },
    {
      "name": "invoice_amount",
      "type": "money",
      "description": "Total amount paid"
    }
  ]
}

Benefits:

• Editors can see available variables
• Validation catches typos like {{custmer_name}}
• You can generate previews and documentation automatically

---

4. Build a WYSIWYG or structured editor

For non-engineers, provide one of these:

Option A: Rich text editor with variable insertion

• Users type normal text
• They click a button to insert variables from a list
• System renders tokens like pills/chips inside the editor

Best for: email/in-app text templates

Option B: Form-based editor

• Separate fields for subject, headline, body, CTA label, footer
• Variables inserted via dropdown or autocomplete

Best for: standardized notifications

Option C: CMS integration

If you already use a CMS (Contentful, Strapi, Sanity, etc.), model templates there and expose only approved fields.

Best for: teams already using content tools

---

5. Add preview and validation

Non-engineers need feedback before publishing.

Include:

• Live preview using sample data
• Validation for required variables
• Warning if a variable is unused or unknown
• Channel-specific limits:
  • SMS length
  • subject length
  • HTML/email-safe content

---

6. Lock down what can be edited

To avoid breaking production notifications:

• Separate content editors from admins
• Require approval/publishing workflow
• Version templates
• Allow rollback to previous versions
• Restrict editing of variable definitions to engineers or admins

A common split:

• Non-engineers: edit text, reorder sections, choose enabled variables
• Engineers: define schema, logic, data mapping, conditional rules

---

7. Support defaults and fallbacks

Variables should have fallback behavior so templates don’t break:

Hi {{first_name | default:"there"}}

Or handle fallback in your rendering layer:

• Missing first_name → “there”
• Missing support_email → a configured default

This makes templates more resilient for editors.

---

A practical model

Template record

• key
• channel
• subject
• body
• locale
• status (draft, published)
• version

Variable catalog

• name
• label
• type
• description
• required
• default_value

Publishing workflow

1. Editor changes content
2. Preview renders with sample data
3. Validation checks variables
4. Approver publishes
5. Old version remains rollbackable

---

Example editor experience

For a “Welcome Email” template:

Subject

• Welcome, {{first_name}}!

Body

• Rich text area
• Variable picker: first_name, company_name, login_link

Preview

• “Welcome, Sam!”
• Body rendered with sample values

---

What to avoid

• Letting non-engineers edit raw handlebars/liquid code with conditions unless they’re trained
• Letting them define arbitrary variables without schema validation
• Storing templates only in application code
• No preview or rollback

---

If you want the simplest workable setup

Start with this:

1. Templates in a database
2. Simple {{variable}} placeholders
3. Admin UI with rich text + variable picker
4. Validation against a schema
5. Preview + versioning

---

If you want, I can also sketch:

• a data model for templates/variables,
• an admin UI wireframe, or
• an implementation using React + Node + Handlebars/Liquid.