OnSched API & dashboard 3.2.0 — dashboard RBAC and SMS templates

Separate SMS and email notification templates

Channel — Notification templates support channel: EMAIL or SMS. Existing rows default to EMAIL; SMS copy can differ while reusing the same merge variables and tooling as email.
Resolution — When sending SMS, the API uses an SMS template if present, otherwise falls back to the email template for that type and recipient (then platform defaults), so behavior stays unchanged until you add SMS-specific templates.
Sending — If a recipient uses both email and SMS (ALL), email and SMS bodies are built separately from the matching channel (or fallback).
API — GET / POST /v3/emailTemplates accept optional channel (default EMAIL). EXTERNAL_CALENDAR_EVENT cannot be saved as SMS (calendar descriptions stay email-only). Database: unique (CompanyId, type, recipientType, channel); run migrations before deploy.
Portal — Notification templates page adds Email | SMS tabs; SMS body is what is sent as plain text after merge (subject is stored but not sent via SMS).

Roles — Owner, Admin, User, and Resource dashboard roles now drive what company data and scheduling entities each login can read or change. Machine integrations using OAuth client credentials are unchanged: access remains scope-based (read/write as today); dashboard role flags on the synthetic principal do not apply.
User location scope — User accounts may have locationAccessMode (COMPANY = all locations, or LOCATIONS with an allowedLocationIds list). Writes and list results for locations, services, resources, and appointments respect this scope (including company-scoped services vs location-linked services).
Resource role — A Resource login is tied to a linkedResourceId and may read non-secret company settings and address, read linked locations/services, and read/write only that resource row. Company responses for this role omit API keys, client secrets, and similar credentials.
User management — Owner may assign any role including Owner. Admin may not assign Owner, may not change another Admin’s role, and may promote User → Admin (per product rules). At least one Owner must remain; demoting the last owner continues to be rejected with the same error the dashboard expects.

setUsers / adjustUsers — Request bodies may include locationAccessMode, allowedLocationIds, and linkedResourceId per user; linkedResourceId is required when the role is resource and must belong to the company. OpenAPI and bundled openapi.json are updated.

Navigation — API Settings is hidden for Resource roles; Company settings tabs that require user management are gated for User roles.
API Settings — User roles can view the page but cannot regenerate or rotate credentials where the API forbids it; Resource roles are redirected away.
Company users — Forms support location scope, allowed locations, and resource linking, with client-side rules aligned to the admin matrix.