Skip to Content
Help Center / Adomo Help Center / Channels Setup (for Admins)

Channels Setup (for Admins)

Who is this for? Workspace admins enabling Email, SMS, Slack, Microsoft Teams, Google Chat, or WhatsApp for the whole workspace. If you're an individual user looking to change how you personally get notified, see the Notifications (for Users) article instead.

Adomo reaches your team where they already work. Once you enable a channel here, each user picks their own preferred order (for example, Slack first, SMS as a fallback) under Settings > Notifications, and Adomo tries their channels in that order until someone responds.

Note: in-app notifications and mobile push need no setup here - they work automatically once a user signs in (to the web app and the mobile app respectively). This page covers only the external channels.

On Adomo cloud workspaces, Email, SMS, Slack, and WhatsApp are preconfigured by the platform - their tabs show "Managed by platform" and there are no credentials to enter. The credential steps below apply to self-hosted deployments. Teams (Graph) and Google Chat are always configured per workspace.

How to set up a channel (at a glance)

  1. Sign in to Adomo as an admin.
  2. Go to Settings > Communication > Channels and pick the tab for the channel you want to enable - Email, SMS, or WhatsApp under Messaging, and Slack (messaging), Teams (Graph), or Google Chat under Bots.
  3. Paste the credentials from the provider (see the guide below for each).
  4. Click Test Connection. Adomo verifies with the provider without sending a real message, so you can set things up safely.
  5. Click Save. The channel is now available for approvals and notifications across your workspace.

Each user then picks how they want to be reached under Settings > Notifications.

Email

Adomo can send email two ways: through a standard SMTP relay (simplest when you already have one), or through Gmail / Microsoft 365 with OAuth2 (recommended for personal Gmail accounts, since Google no longer allows basic-auth SMTP from most accounts). Google Workspace domains can alternatively choose Auth type service_account and paste a service account JSON key with domain-wide delegation, instead of a refresh token.

Email option A: SMTP relay (basic)

Works with services like SendGrid, Postmark, Amazon SES, Mailgun, or your own corporate mail server.

  1. Create (or log in to) your relay account and create an API key or SMTP credentials.
  2. In Adomo under Settings > Communication > Channels > Email, fill in:
    • SMTP host and SMTP port (usually 587 with STARTTLS, or 465 with SSL).
    • From address - must be a verified sender on your relay.
    • SMTP username and SMTP password (the API key or credentials from step 1).
  3. Leave Auth type on basic.
  4. Click Test Connection, then Save.

Email option B: Gmail with OAuth2

Best for personal Gmail or Google Workspace accounts.

  1. In Google Cloud Console > Credentials create a project and add an OAuth 2.0 Client ID (Web application).
  2. Enable the Gmail API.
  3. Use the OAuth Playground (or your own flow) to obtain a refresh token for the scope https://mail.google.com/. In the Playground, click the gear icon, tick Use your own OAuth credentials, and paste your Client ID and Secret. Important: if your OAuth consent screen is in Testing status, refresh tokens expire after 7 days and the email channel will stop working. Set the consent screen user type to Internal (Google Workspace) or publish the app to Production before generating the refresh token. If the channel later fails this way, you'll see the failures under Settings > Communication > Activity; the fix is to regenerate the refresh token and re-run Test Connection.
  4. In Adomo under Settings > Communication > Channels > Email, set:
    • SMTP host: smtp.gmail.com
    • SMTP port: 465, Use SSL: on
    • Auth type: oauth2
    • Paste Client ID, Client Secret, Refresh Token, and Username (the Gmail address you're sending from).
  5. Click Test Connection, then Save.

Email option C: Microsoft 365 / Outlook with OAuth2

  1. Register an app at Azure AD > App registrations.
  2. Add the delegated permission SMTP.Send on Microsoft Graph and grant admin consent.
  3. Obtain a refresh token via the authorization code flow.
  4. In Adomo under Settings > Communication > Channels > Email, set:
    • SMTP host: smtp.office365.com
    • SMTP port: 587
    • Auth type: oauth2
    • Paste the Client ID, Secret, Refresh Token, and your mailbox address.
  5. Click Test Connection, then Save.

How Test Connection works for email. Adomo logs in to your SMTP server to verify authentication. No email is sent, so there's no delivery or charge.


SMS (Twilio)

Adomo uses Twilio for SMS delivery. You'll need a Twilio account and a provisioned phone number.

Before you start: for US traffic, begin Twilio brand and campaign registration (10DLC or toll-free verification) first - approval can take days to weeks, and carriers filter or block messages from unregistered numbers. Twilio trial accounts can only send to verified numbers; upgrade before rolling out to your team.

  1. Sign up at twilio.com/try-twilio. The free trial includes a provisioned number.
  2. In the Twilio Console home panel, copy the Account SID and Auth Token.
  3. Under Phone Numbers > Active numbers, copy a number in E.164 format (for example +14155551234).
  4. In Adomo under Settings > Communication > Channels > SMS, paste the Account SID, Auth Token, and the From Number.
  5. In Twilio Console under Phone Numbers > Active numbers > your number > Messaging configuration, set "A message comes in" to Webhook (HTTP POST) and paste Adomo's SMS inbound endpoint URL (your account team, or the deployment docs for self-hosted installs, have the exact URL for your deployment). This enables the automatic STOP / HELP handling described below.
  6. Click Test Connection, then Save.

SMS compliance: opt-in consent (required)

Adomo blocks SMS dispatch to any number until a recorded consent exists for that number. To make that work, fill in the two compliance fields on the SMS admin page. The proof URL is required - SMS is treated as unconfigured without it and users cannot record consent. The disclosure is optional.

  • SMS Opt-In Proof URL (required) - a public URL that describes how your end users opt in to SMS. This is the URL you submit to Twilio / the downstream carriers during brand and campaign registration. Adomo ships with a ready-to-use public article, SMS Messaging and Opt-In, in this help center: open that article in your browser while signed out and copy the address from the address bar. Users also see this link next to the consent checkbox in their Notifications settings.
  • SMS Opt-In Disclosure (optional) - the short consent text shown to users when they add an SMS contact method. A built-in default consent text is shown to users if you leave it blank; override it only if your legal or compliance team requires different wording. Example: > I consent to receive transactional SMS from this platform at > the number above. Reply STOP to opt out. Msg & data rates > may apply.

After you save these, users see the disclosure text + the proof URL + a consent checkbox when they add their phone number under Settings > Notifications. They must tick the checkbox for SMS to dispatch; otherwise outbound notifications fall through to the next channel in their preference order.

For external authorities (outside approvers who don't sign in to Adomo directly), admins attest consent on behalf of the external authority under Settings > DOAG policy > External Authorities.

SMS compliance: STOP / HELP handling

Adomo handles inbound carrier keywords automatically through the Twilio inbound webhook:

  • STOP, STOPALL, UNSUBSCRIBE, CANCEL, END, QUIT - the number is added to the workspace's suppression list and no further SMS is sent to it, regardless of consent status.
  • START, UNSTOP, YES - the number is removed from suppression.
  • HELP, INFO - a TwiML help reply is returned automatically.

No ongoing admin action is required - once your Twilio number's inbound message webhook points at Adomo's SMS inbound endpoint (setup step 5 above), the behavior is automatic.

US registration (10DLC, toll-free, short code)

For US traffic you must register a brand and campaign in Twilio before messages deliver reliably. See Twilio's 10DLC guide for long codes, or the equivalent toll-free verification / short-code flow for those number types. For EU traffic, follow Twilio's regional equivalent.

During registration, paste the SMS Opt-In Proof URL you configured above into the "proof of consent" field that Twilio and the carriers require.

SMS reference: contact format, Test Connection, and usage scope

Contact methods for the SMS channel are E.164 phone numbers (+14155551234).

How Test Connection works for SMS. Adomo verifies your credentials by calling a read-only Twilio endpoint. No SMS is sent, so you aren't charged.

Before you enable SMS for your workspace. Read the SMS Messaging and Opt-In article in this help center and confirm your workspace's usage is consistent with it (operational messages only, never marketing, recipients opt in via the app). If you need to send message types or volumes outside that scope, contact your account team first.


Slack

Adomo posts approval requests and notifications to Slack through the Adomo Slack app installed in your Slack workspace.

On Adomo cloud, Slack is managed by the platform: a workspace admin authorizes the Adomo Slack app into your Slack workspace through a standard "Connect to Slack" OAuth consent screen. There is no app to create and no token to paste, and the Slack tab under Settings > Communication > Channels shows the channel as managed by the platform.

On self-hosted deployments, you can register your own Slack OAuth app instead:

  1. Go to api.slack.com/apps > Create New App > From scratch. Give it a name (for example "Adomo") and pick the target workspace.
  2. Open OAuth & Permissions > Scopes and add these Bot Token Scopes:
    • chat:write - post messages
    • chat:write.public - post to channels the bot isn't a member of
    • users:read.email - resolve users by email
    • im:write - open DMs for per-user approval routing
  3. In Adomo under Settings > Communication > Channels > Slack (messaging), enter the Client ID, Redirect URI, and Client Secret from your Slack app, then Save and complete the OAuth authorization into your Slack workspace.
  4. (Optional) Invite the bot to any channel it should post to (/invite @adomo). With chat:write.public you can skip this.

Pasting a manually generated bot token (an xoxb- token) is a legacy setup path. Existing workspaces that configured one keep working, but new setups should use the OAuth flow above.

Slack messages from Adomo are notifications only - to respond to a standard approval, open the Approvals page in Adomo. Approval cards sent to external authorities under a DOAG policy include Approve / Reject buttons that open the request in Adomo in your browser; responses are recorded in the app, not in the Slack thread.

Contact methods for Slack accept any of:

  • user email
  • @username
  • a Slack user ID like U01ABCDEFG
  • a channel like #channel or a channel ID C01ABCDEFG

How Test Connection works for Slack (self-hosted only; the cloud tab is managed by the platform and has no test button). Adomo calls Slack's auth.test endpoint to verify the connection. No message is posted.


Microsoft Teams - Incoming Webhook (simple, one channel)

Use this option if you just want approval cards posted to a single Teams channel. Everyone in that channel can see the card. This is quick to set up but not suitable for sensitive approvals - there's no per-user identity. For DMs, group chats, or per-user routing, use the Teams (Graph) option below instead.

  1. Create the webhook in Microsoft Teams. In newer tenants, Connectors have been retired, so use the Workflows app: open the target channel, pick ... > Workflows, choose the template Post to a channel when a webhook request is received, and copy the generated URL. In tenants that still show Connectors, use ... > Connectors > Incoming Webhook > Configure, give it a name (for example "Adomo Approvals"), click Create, and copy the URL.
  2. In Adomo, go to Settings > DOAG policy > External Authorities, add or edit an authority, choose Teams (Webhook) as the contact method channel, and paste the webhook URL as the address.
  3. Click the Test button next to the contact method. Teams webhooks have no silent verify on Microsoft's side, so Adomo posts a small "Connection test" card to the channel - everyone in the channel can see it. Then save the authority.

There is no workspace-level Teams webhook credential and no Teams webhook tab under Settings > Communication > Channels; each webhook URL targets exactly one channel. Teams (Webhook) also can't be added as a personal contact method under Settings > Notifications - it appears there only in the channel preference order.

Limitations. Webhooks post to exactly one channel, only support "Open URL" buttons, and have no user identity. In short: Approve and Reject buttons do not work inside Teams with the webhook option; only the Teams (Graph) option with Bot mode enabled supports in-chat Approve and Reject. Don't use webhooks for sensitive approvals.


Microsoft Teams - Graph (per-user DMs, group chats, channels)

This is the full Teams integration. It supports 1:1 direct messages, group chats, and channel posts, and it preserves per-user identity so only the right person can approve.

Before you start: you'll need an Entra ID admin who can grant tenant-wide admin consent, and (for Bot mode) a Teams administrator who can upload custom apps in Teams Admin Center.

Teams (Graph) step 1: Register an app in Azure AD

  1. Open Azure Portal > App registrations and click New registration.
  2. Name it (for example "Adomo Teams Approvals") and choose Accounts in this organizational directory only.
  3. From the app's Overview page, copy the Application (client) ID and the Directory (tenant) ID.

Teams (Graph) step 2: Add API permissions

Under API permissions > Add a permission > Microsoft Graph > Application permissions, add:

  • Chat.ReadWrite.All - create and post 1:1 / group chats
  • User.Read.All - resolve users by email / UPN
  • Organization.Read.All - used by Test Connection
  • ChannelMessage.Send - only needed if you'll post to team channels

Click Grant admin consent for <your tenant>. Every row must show the green checkmark.

Teams (Graph) step 3: Create a client secret

Under Certificates & secrets > Client secrets > New client secret, create one and copy the Value (not the Secret ID). This is shown only once.

Teams (Graph) step 4: Save the credentials in Adomo

In Settings > Communication > Channels > Teams (Graph), paste the Client ID, Tenant ID, and Client Secret. Click Test Connection, then Save.

Teams (Graph) step 5: (Optional) Enable in-chat Approve / Reject buttons

By default, Teams messages include an Open Adomo button that takes the approver to the Adomo approvals page in a browser. If you want the Approve and Reject buttons to work directly inside the Teams chat:

  1. Create an Azure Bot resource. Choose Multi-tenant and reuse the App ID from step 1 (or create a new one).
  2. Set the bot's messaging endpoint to the URL shown in Adomo under Settings > Communication > Channels > Teams (Graph) > Bot mode (copy the URL displayed there; it's specific to your workspace).
  3. In the bot's Channels blade, add the Microsoft Teams channel.
  4. Author a Teams app manifest for the bot. The easiest path is Teams Developer Portal, which lets you edit the manifest visually; otherwise see the manifest schema docs. Export the .zip package.
  5. Upload the manifest to Teams Admin Center > Manage apps > Upload new app. Users in your tenant then install the app (or an admin pre-installs it). Proactive 1:1 DMs only deliver after install.
  6. In Adomo, enable Bot mode and paste the Bot App ID.

Contact methods for Teams (Graph)

Any of:

  • [email protected] - resolved by email or UPN (delivers a 1:1 DM)
  • user:<aad-object-id> - direct Azure AD user ID (1:1 DM)
  • group:<chat-id> - existing Teams group chat
  • team:<teamId>/channel:<channelId> - post in a team channel

Google Chat

Adomo posts to Google Chat through a Google Cloud service account. It can post into Chat spaces, and (optionally) send 1:1 DMs by email address. Users can also message the Adomo Chat app directly to chat with Adomo from inside Google Chat.

Google Chat step 1: Create the Google Cloud pieces

  1. In Google Cloud Console, create (or pick) a project and enable the Google Chat API.
  2. Create a service account under IAM & Admin > Service Accounts and download a JSON key for it.
  3. On the Chat API's Configuration page, set up the Chat app: give it a name (for example "Adomo"), an avatar, and a description, and make it available to your domain. Then add the app to the spaces it should post in (or let users add it).

Google Chat step 2: (Optional) Enable DMs by email

To let Adomo DM users by their work email, grant the service account domain-wide delegation:

  1. In Google Admin console under Security > Access and data control > API controls > Domain-wide delegation, add the service account's client ID with these scopes:
    • https://www.googleapis.com/auth/chat.spaces
    • https://www.googleapis.com/auth/chat.spaces.create
    • https://www.googleapis.com/auth/chat.messages
    • https://www.googleapis.com/auth/chat.messages.create
  2. In Adomo, fill in Delegated User Email with a Workspace user the service account may impersonate when sending.

Without delegation, Adomo can still post to any space the Chat app has been added to; it just can't open 1:1 DMs.

Google Chat step 3: Save the credentials in Adomo

In Settings > Communication > Channels > Google Chat, fill in:

  • Service Account Key (JSON) - paste the full contents of the JSON key file. (Required.)
  • Default Space ID - optional, for example spaces/AAAAxyz. Used when a notification doesn't specify a space; can be overridden per recipient.
  • Delegated User Email - optional, see step 2.
  • Enable Chat App (in-chat Approve/Reject buttons) - optional. When on, approval cards use interactive buttons that resolve right in the chat instead of opening a browser. Requires setting the Chat app's endpoint URL in Google Cloud Console to the URL shown on the Adomo setup page.
  • Google Cloud Project Number - optional, used to verify that button clicks really come from Google. Find it on the Google Cloud Console dashboard. Recommended whenever the Chat App is enabled.

Click Test Connection, then Save.

Contact methods for Google Chat accept either of:

  • spaces/AAAAxyz - post in a specific Chat space
  • [email protected] - DM the user (requires domain-wide delegation)

How Test Connection works for Google Chat. Adomo validates the service account key, obtains an access token from Google, and checks that it can reach the configured space (or list spaces if none is configured). No message is sent.


WhatsApp (Meta WhatsApp Business Cloud API)

Adomo uses Meta's WhatsApp Business Cloud API. You'll need a Meta developer account, a WhatsApp Business Account (WABA), and a verified phone number. WhatsApp requires pre-approved message templates for any message sent outside a 24-hour active conversation - this is Meta's rule, not Adomo's.

  1. Create a Meta app at developers.facebook.com/apps. Choose Business as the app type.
  2. Add the WhatsApp product. Meta gives you a test phone number you can use immediately. For production, add and verify your own number.
  3. Copy the Phone number ID (numeric).
  4. In Meta Business Manager, create a System User and generate a permanent access token with the whatsapp_business_messaging and whatsapp_business_management permissions.
  5. In Adomo under Settings > Communication > Channels > WhatsApp, paste the Phone number ID and the access token.
  6. Click Test Connection, then Save.

Adomo sends interactive approval messages, which Meta only delivers within a 24-hour active conversation with the recipient. Template-based delivery outside that window is not currently supported - contact your account team if you need it.

Contact methods for WhatsApp are E.164 phone numbers (+14155551234).

How Test Connection works for WhatsApp. Adomo fetches phone-number metadata from Meta's Graph API. No WhatsApp message is sent.


Admin FAQ

Can I enable more than one channel at once?

Yes. Enable any combination. Each user then picks their own preference order under Settings > Notifications.

Can I test channels without bothering real users?

Yes. Test Connection on each channel verifies credentials with the provider without sending a real message. The one exception is the Teams webhook contact method: it has no silent test option on Microsoft's side, so the Test button in the External Authorities contact-method editor posts a small "connection test" card to the channel only.

Where do I see delivery history?

Each approval's timeline in the Adomo app shows which channels were attempted, in what order, and what the response was. Admins can also view cross-workspace delivery activity under Settings > Communication > Activity.

What happens if a user hasn't set any contact methods?

The approval still records, and the user sees it in-app when they next sign in. No outbound message is sent. Remind users to set their contact methods under Settings > Notifications after you enable channels.

What happens if a channel fails for a given user?

Adomo tries the next channel in that user's preference order. If nobody responds within the step's configured time window, the step's timeout action runs. Depending on how the process author configured the step, the request can auto-approve, auto-reject, or fail the run. Before the window expires, steps can also send reminders and escalate to additional approvers through the escalation chain configured on the step. The timeout is logged either way.

Test Connection failed - what do I check?

Re-check the credentials you pasted, then the usual provider-side causes: for SMTP, the port and SSL setting; for Teams (Graph), that admin consent was granted on every permission; for Google Chat, that the service account key is valid and the Chat API is enabled; for WhatsApp, that the access token hasn't expired. Fix the cause and re-run Test Connection.

Delivery to one user failed - where do I look?

Check Settings > Communication > Activity for the provider's error. Most often the user's contact method doesn't match their identity in the provider (their Slack account uses a different email, or their Teams address isn't their sign-in UPN), or a Google Chat DM was attempted without domain-wide delegation. Adomo falls through to the user's next preferred channel either way.

How do I rotate a credential?

Open the channel's tab in Settings > Communication > Channels, paste the new credential, click Test Connection, then Save. Previous credentials are overwritten. On Adomo cloud workspaces, Email, SMS, Slack, and WhatsApp credentials are managed by the platform - there is nothing to rotate yourself.

Where do approvers actually change their own preferences?

They do it themselves under Settings > Notifications (see the Notifications (for Users) article). Admins don't manage per-user contact methods.

Need more help? Contact Us