Email and SMS delivery settings
Delivery settings connect workspace notifications to an email or text-message service. They are separate from personal notification choices and from identity providers used to sign in. Obtain the connection details from your organization's delivery administrator before changing them.
Access needed
Access depends on your assigned permissions and workflow scope.
- Read/save/clear delivery configuration and send a caller-only test
notifications.settings.manageThis grant is required for reads and writes. Tests use saved settings and the signed-in caller’s destination. Inbox, template and Identity permissions do not substitute.
Role and permission labels
Typical responsibility: Authorized delivery administrator. Role names alone do not grant access.
- Manage notification delivery settings
- Open the delivery-test history
notifications.deliveries.readIndependent of settings administration. Saving providers does not require log-read access.
Role and permission labels
Typical responsibility: Authorized delivery investigator. Role names alone do not grant access.
- Read outbound notification delivery history
Demo screenshots may show broader access than your account.
Check the current delivery source
Open Settings → Delivery settings. Review the Email provider and SMS provider summaries before editing. If no workspace provider is saved, the platform provider is used when one is available. The demo explicitly reports that neither platform fallback is available.
A provider selected in an empty form does not prove that provider is configured. Read the saved-state summary and secret indicators. A missing provider can explain EMAIL_NOT_CONFIGURED in the Delivery log.
Configure email
- Choose the provider and sender
Select the supported Email provider and enter Sender email and optional Sender name. Use the sender identity supplied or approved by your delivery administrator.
- Enter its connection details
SMTP uses the supplied public hostname, port, security and any required username/password. Enter a hostname without a URL scheme or port suffix. SendGrid uses its own key rather than SMTP connection fields.
- Review secret handling
Use the secret action intentionally: keep an existing saved secret when it should remain, or enter a replacement through the protected field. An empty replacement is not proof that the old secret was removed.
- Save and verify
Review the pending changes and save through the form's save controls. Check validation errors, then reload the settings to verify the saved configuration before testing it.
SMTP requires STARTTLS or SSL-on-connect security; unencrypted SMTP is not accepted. Public-host validation also excludes localhost and private addresses. Use your organization's approved connection values rather than copying the demo's initial port or security choice blindly.
Configure text messages
Review the SMS provider summary, then choose the supported provider. The form shows the fields required by that provider; do not mix credentials from different provider types.
| Provider | What to prepare |
|---|---|
| Twilio | Approved Sender ID, account SID and auth token. Sender ID is an international-format number or messaging-service identifier. |
| HTTP gateway | Approved public HTTPS destination, supported method/content type, required message template and provider headers. |
A first Twilio save requires an auth token. An HTTP gateway has its own configuration and cannot use Twilio credentials as substitutes. When SMS absence reporting is configured, its inbound number must identify the correct workspace and cannot be shared by two workspaces.
SMS delivery also depends on valid recipient mobile numbers. Configuring a provider does not fill missing employee numbers or change their personal notification choices.
Test saved settings
Use Send test email or Send test SMS, review the confirmation, then select Send test only when you intend to transmit a real message. Tests use the saved configuration; unsaved fields are not used.
Read the reported success or failure, then use Delivery test log when you have delivery-history permission. Test attempts appear under the delivery-test category. A completed request can still report a sending failure, so check the result rather than assuming the button succeeded.
Provider acceptance is not proof that the person received or read the message. See Delivery log for status meanings and failure investigation.
Clear a workspace provider carefully
When clearing saved workspace configuration is offered, review the channel and confirmation before proceeding. Clearing removes its workspace settings and secrets and falls back to the platform provider only if one is available. Without a fallback, that outbound channel may stop working. Clearing SMS settings also releases its configured inbound number.
Troubleshooting
| Problem | What to check |
|---|---|
| Settings cannot be opened | Reading and changing delivery configuration require notifications.settings.manage. |
| A fallback is shown but messages fail | Check whether the summary says a platform provider is actually available. |
| Test ignores new form values | Save first; tests use saved configuration only. |
| SMS test reports an invalid recipient | Check your own directory mobile number through its authorized workflow. |
| A saved secret is not visible | Secrets are withheld; use the indicator and keep/replace controls. |
| Delivery test log is unavailable | It separately requires notifications.deliveries.read. |
| Personal preferences show SMS unavailable | Check saved provider availability, not just the provider selected in a draft. |
What was verified
The live empty email/SMS provider forms, fallback summaries and SMS test confirmation were inspected in light theme. Three screenshots reuse the shared viewer. The confirmation was cancelled. No provider, secret or destination changed and no test message was sent. Successful provider setup, clearing and actual delivery remain untested.