Skip to main content
Version: v0.25.0 (Latest)

Branding and email

Branding is how this tenant presents itself on product surfaces: app name, primary colour, logos, favicon, login screen extras, and the shell around outbound email. Email is how the tenant actually sends mail: SMTP (or equivalent) accounts, which account handles which message type, and the subject/body templates for each type.

These are related but separate:

  • Branding answers "what does Acme look like?"
  • Email answers "how does Acme deliver activation and password messages?"

Email design (under Branding) styles the HTML shell around templates. Templates (under Email) supply type-specific content and variables. Accounts and routing decide which SMTP identity sends each type.

Whether sample brand or accounts already exist depends on product onboarding and sample data. A clean tenant may show empty forms or product defaults until you save.

Audience: tenant admin (or platform operator working in a tenant or platform-management context).

Prerequisites: Onboard a tenant. Hosted login and owner invitations need a working authorization server and, for real mail delivery, reachable SMTP (or lab mail sink).

Reference: Simple brand, Login screen, Email design, Applications, Accounts, Routing, Templates.

APIs: Theme (paths under theme), Platform config (email accounts, routing, templates).

Simple brand​

Tenant-global identity used as the default for portals, wallets, and the admin shell when no application override applies.

FieldWhy it matters
App nameTitle in chrome and browser context for branded apps. After save, tenant theme resolution can apply it to the console for that tenant.
Primary colourDrives generated design tokens (buttons, links, focus). Choose a colour with enough contrast on light and dark surfaces.
Secondary colourOptional accent; omit if you only need one brand colour.
Logo / logo dark / faviconLight and dark logos avoid washed-out marks on dark UI. Favicon is what operators see in browser tabs.
TaglineShort line under the name on login and email when those features show it.

Save publishes the brand. Reload discards unsaved edits. Generated token counts on the form are diagnostic, not something you edit by hand in Simple brand.

Navigation: Resources > Branding > Simple brand
Deep link: #resource=branding&rarea=simpleBrand

Simple brand editor

Login screen​

Login-specific design elements for the authorization server product (tagline, background, and related bindings). These sit on top of the tenant simple brand so sign-in can use a different background or tagline without changing wallet chrome.

Preview light and dark before save. Broken background assets produce empty previews, not a failed login, until holders hit production AS pages.

Navigation: Resources > Branding > Login screen
Deep link: #resource=branding&rarea=loginScreen

Login screen branding

Email design​

The branded shell around outbound HTML mail: header logo (and dark logo), header style, whether the tagline shows, button and corner style, footer note, support URL and support email.

This is not the per-type subject line or body. Those live under Email > Templates. Change email design when the corporate mark or footer must change for every message type at once.

Elements can inherit from the tenant brand tokens (for example logo from simple brand) until you override them here.

Navigation: Resources > Branding > Email design
Deep link: #resource=branding&rarea=emailDesign

Email design branding

Applications​

Registered product applications (authorization server, web wallet, mobile wallet, portal, custom) that can carry per-application brand overrides. Managed applications appear because the platform registered them; you can register additional ones when the product allows.

Use overrides when one surface must not share the tenant primary colour (for example a separate workforce portal). Leave overrides empty to inherit Simple brand.

Navigation: Resources > Branding > Applications
Deep link: #resource=branding&rarea=applications

Branding applications list

Email accounts​

An email account is a named SMTP sender the tenant owns: who the message appears from, which server accepts it, and how credentials and TLS are applied. Product flows (owner activation, password change, invitations, wallet security notices) do not open a raw socket. They resolve a route to an account, then hand the composed message to that account's transport.

Without at least one working account, those flows queue or fail at send time (except lab sinks wired by deployment). Branding and templates still edit fine offline; only delivery needs accounts.

What the list shows​

ColumnMeaning
AccountDisplay name, stable account id, and a Local default badge when this account is the tenant routing default.
SenderFrom name and from address as recipients see them.
SMTP serverHost and port used for outbound submission.
CredentialsWhether a password (or product secret ref) is stored. The console never displays the secret after save.
ModeHow the account is managed (for example external SMTP).
StatusLifecycle (active, disabled). Disabled accounts must not stay as the default.

Row actions: Send test, Edit, Make default (when not already default), Delete. Delete is blocked while the account is the local default or while a purpose-specific route still points at it. Point routing elsewhere first, then delete.

Navigation: Resources > Email > Accounts
Deep link: #resource=email&rarea=accounts

Email accounts list

Create or edit an account​

New account (or Edit on a row) captures identity and transport. Account id is fixed after create and is what routing references.

FieldWhy it matters
Account IDStable key (support, noreply). Used by routing and APIs. Letters, digits, underscore, hyphen; start with a letter or digit.
Display nameOperator-facing label in lists and default-badge notices.
From addressEnvelope and header From. Must be a mailbox your SMTP provider authorizes for this host (SPF/DKIM alignment).
From nameHuman-readable sender (for example "Acme Support").
Reply-toOptional alternate inbox when From is no-reply. Leave empty if replies should go to From.
SMTP host / portSubmission endpoint. Common: 587 with STARTTLS, 465 with implicit SSL.
UsernameOften the same as From, sometimes a separate relay user.
SMTP passwordWritten once into the account credential store. On create it is optional only if the host allows unauthenticated relay (rare outside labs). On edit, leave blank to keep the existing secret; enter a new value to rotate. The browser does not retain the password after submit.
Use STARTTLSUpgrade a clear connection (typical on 587).
Use implicit SSL/TLSTLS from the first byte (typical on 465). Do not enable both against the same port unless your provider documents that combination.
Connection / read timeout (ms)Fail fast on dead hosts so product sends do not hang operator workflows. Defaults (5000 / 10000) suit most SaaS SMTP. Raise only for slow enterprise relays.

Prefer separate accounts (and credentials) per environment and purpose when possible: a support mailbox for human-facing mail, a no-reply for automated activation, different credentials in lab vs production. Shared credentials make rotation and incident response harder.

New email account dialog

Default sender and test send​

Make default sets this account as the tenant local default used by routing for every email type that does not have a purpose-specific assignment. Types with an explicit assignment keep that account. Platform-level fallback still applies when the tenant has no default and no assignment.

Send test opens a small dialog: recipient, subject, plain body. The platform submits through this account's SMTP only. Use it after create or password rotation, and after firewall or DNS changes. A successful test does not prove SPF/DKIM for production domains; it proves the account can authenticate and hand off a message. Template test-send (on the template Preview tab) additionally exercises catalog composition and the effective route for that type.

If test send fails, check host/port, STARTTLS vs SSL, username/password, and whether the From address is allowed on that relay. Fix the account before chasing template markup.

Email routing​

Routing maps email type (password change, invitation, and so on) to an account, with a default account for types without a specific assignment. You can disable a type entirely when the product should not send that message.

Wrong routing sends invitations from the wrong mailbox or drops types you meant to keep. Set a default first, then special-case types that need a different from-address.

Navigation: Resources > Email > Routing
Deep link: #resource=email&rarea=routing

Email routing policy

Email templates​

Per email-type content: subject, preheader, HTML fragment, plain-text body, and locale variants. Templates supply the type-specific copy; they render inside the email design shell (header logo, footer, colours). Variables come from the email type catalog (for example landingUrl, displayName).

The catalog lists built-in product types (password change, owner activation, invitations, and so on) plus any custom types you add. Filter by origin (built-in vs custom) and status (draft vs published). Email design in the header jumps to the shell editor when logos or footers are wrong for every type at once. Do not paste corporate marks into each HTML body if the shell already carries them.

Navigation: Resources > Email > Templates
Deep link: #resource=email&rarea=templates

Email templates list

Open a template (content)​

Click a type name (for example Password change) to open the workspace. Tabs:

  1. Content: locales, subject, preheader, personalization tokens, content blocks, rich HTML and plain-text bodies
  2. Preview & test: render with sample data, optional routed test send
  3. History: published revisions and copy-to-draft rollback

On Content, set the locale you are editing and the default locale for fallback. Insert catalog variables ({{landingUrl}}) into subject, preheader, HTML, or text. Content blocks (CTA, panel, meta) add email-safe markup without free-hand HTML for every case. Save draft writes a new draft revision; Publish promotes that draft for production senders. Product defaults remain product defaults until you save a tenant override; Preview does not write an override by itself.

Password change template content editor

Preview & test (after Preview)​

Open Preview & test, then click Preview. The console sends the current editor content (including unsaved edits) with sample variables for the type. The panel shows resolved subject, locale, branding source, revision, and a sanitized HTML iframe (desktop or mobile width). Expand plain-text preview when you need the text alternative.

Preview alone does not deliver mail. Send routed test (with a recipient) first saves the draft, then submits through the effective account for this type from routing. Use Preview for copy and layout; use routed test when you need SMTP and route proof for this type.

If the shell looks wrong in the iframe, fix Email design. If the wrong From address appears on a real send, fix routing or accounts. If variables are empty or wrong, fix the type catalog or the runtime that supplies them, not only the subject line.

Password change template after Preview
  1. Set Simple brand (name, colour, logos).
  2. Adjust Login screen if sign-in needs different art.
  3. Adjust Email design for the mail shell.
  4. Register Applications overrides only where needed.
  5. Create Email accounts and prove SMTP.
  6. Set Routing default account and special types.
  7. Review Templates subjects and bodies per locale.

After branding and email​

  1. Onboard a tenant owner login delivery depends on mail when email is healthy
  2. Hosted login and wallets pick up brand via theme resolution
  3. Keep SMTP secrets out of source control; rotate credentials in the account editor

Next​