Q-Assist for Salesforce — Partner Overview

October 2026

What Q-Assist is

Q-Assist puts a company's WhatsApp Business conversations inside Salesforce. Reps read and reply to customers on WhatsApp from any Lead, Contact, Account or custom record page, and every message is stored as a Salesforce record.

It is built for sales and service teams that already sell and support over WhatsApp, often from personal phones, and need that conversation in the CRM: visible to managers, tied to the right record, and sent from company numbers rather than individual handsets.

• No middleware for the partner to build. Q-Assist runs the WhatsApp side (Meta Cloud API, webhooks, queues, retries); the Salesforce side is a set of FAS_-prefixed objects, Apex and Lightning components deployed into the org.
• Salesforce stays the place reps work. One drag-and-drop chat component on record pages, plus a Q-Assist app with an inbox (Home) and an admin Settings page.
• Requires Enterprise Edition or above (API access is needed in both directions).

AI workflows

Q-Assist runs full AI workflows on WhatsApp: an AI agent answers first, qualifies the customer or lead, gathers what the team needs, and hands over to the right rep in Salesforce with the context already captured. Every workflow is built for the customer's business.

In Salesforce. Everything the AI says is synced as ordinary messages, so the rep sees the whole conversation on the record. Qualified enquiries can become Leads routed to the right queue per business number, with the AI's answers captured.

Built per customer, by Q-Assist. Q-Assist designs and builds every AI workflow and bot with the customer: the questions, the qualification rules, the tone, the handover points and the hours the AI covers.

Q-Assist's own AI, running outside Salesforce. The AI and bots are Q-Assist's own, not Agentforce or Einstein. They run entirely in the Q-Assist service, so nothing AI-related runs inside the org: no Agentforce or Einstein licences, no AI credits, and no Salesforce API calls or Apex limits used while the AI works. Salesforce only receives the results, as messages and records.

What it can do

Reps get a full WhatsApp chat on any record page; admins control who uses which number, and every message lands in Salesforce within seconds. Measured on a live thread: inbound message to Salesforce in 2.7 s, a reply from Salesforce delivered in about 2 s.

For reps

For admins

• One Settings page with tabs for users, numbers, files and replies, business hours, record linking, conversations and health. Covered in full under Settings reference.
• Business hours, holidays, out-of-office and scheduled auto-replies, managed from Salesforce.
• A Health tab showing connection status, scheduled jobs, org storage and API use, and any stuck or failed sends.

Also included

• WhatsApp templates — reps pick a Meta-approved template, fill in its variables and send. Templates start new conversations from any record and reopen a conversation after the 24-hour window.
• Voice notes from Salesforce — record, listen back and send as a native WhatsApp voice note, up to 7 minutes. Switched on per org in Settings.
• Typing indicator — shows when another rep is already replying to the same customer, so two people don't answer at once.
• Manager reporting tab — conversation volumes, response times and activity per rep and per number, alongside standard Salesforce reports on the message records.

How it works

Q-Assist sits between Meta's WhatsApp Cloud API and Salesforce. It receives every message, writes it into the org as a record, and sends reps' replies to WhatsApp after checking they are allowed to.

A message in. The customer writes; Meta delivers it to Q-Assist; Q-Assist upserts a FAS_Message__c record and fires an event so any open chat refreshes. Delivery and read receipts update the same record.

A reply out. The rep sends from the chat. Salesforce saves the message as Pending first, then calls Q-Assist. Q-Assist checks the rep's licence, the number and the 24-hour window, queues the send and answers within about a second. If the call fails, Salesforce retries within minutes and a scheduled sweeper catches anything left. Every send carries a unique key, so a retry never reaches the customer twice.

Files sent by reps stream from Salesforce Files to WhatsApp without passing through Apex, so size limits are WhatsApp's own. Files from customers are copied into Salesforce Files according to the copy settings.

The Q-Assist mobile app works on the same conversations, so reps can reply from their phones under the same licence and number rules.

Multiple WhatsApp numbers

One Salesforce org can run several WhatsApp Business numbers, for example one per branch, brand or team. Each number keeps its own conversations and its own 24-hour window with each customer.

• Registered in Settings → Numbers. Each number is a FAS_BusinessNumber__c record with a description reps see ("Cape Town Sales"), the number itself and Meta's phone number ID. Settings checks each entry against the numbers Q-Assist actually holds and pre-fills the ones it finds.
• One card per number in the chat. If a customer has talked to two of the company's numbers, the record page shows two cards, each in its number's colour and labelled with its description. The most recent is open; the others fold to one line.
• Replies go out on the right number. Every send names the number it is sent from. A reply in the Cape Town card goes from the Cape Town number, never from whichever number the customer used last.
• Every message records its number (FAS_BusinessNumber__c and FAS_BusinessNumberId__c on conversations and messages), so reports and automation can split by number.
• Adding a number is a Q-Assist onboarding step (Meta app, number registration, webhook), then one record in Settings. No deploy is needed on the Salesforce side.

How access is scoped per user

Three independent layers decide what a user can do: a permission set says which parts of the app they see, a licence says whether they may send, and number assignments say whose conversations they see.

1. Permission sets

No profiles are used. Every rule the components enforce is checked again on the server, so the UI is never the only gate.

2. Licences (who may send)

• Admins pick licensed users in Settings → Users. Only licensed users can send; anyone else can read but the composer refuses.
• The licence list is held by Q-Assist, not in Salesforce data, and the send is checked there. Editing Salesforce records cannot grant a licence.
• The seat count is set by Q-Assist per customer. Settings only lets an admin pick as many users as there are seats left, and says so plainly ("2 seats remain on your plan of 10").
• Billing is on distinct users licensed during the period.
• Removing a licence also switches off that user's Q-Assist mobile app.

3. Number access (whose conversations they see)

• In Settings → Numbers, each number can have users assigned. A number with no users is seen by everyone. Once it has users, only they see its conversations.
• A user can work several numbers, and a number can have several users.
• System administrators and holders of FAS_All_Conversations see every number.
• This is real Salesforce record sharing, not a filter in the component, so reports, list views and global search respect it too.
  • FAS_Conversation__c is Private. FAS_Message__c is its master-detail child, so messages follow their conversation.
  • Each number has a public group (FAS_WA_<phone number id>) kept in step with its assigned users. Each conversation is shared with its number's group.
  • Reassigning users only changes group membership; Salesforce recalculates access without rewriting records.
• The same assignments are pushed to the Q-Assist mobile app, which shows each user only their numbers and only notifies them about those.

When a user is deactivated

An admin chooses the behaviour once, in Settings → General:

Settings → Health lists closed numbers and any inactive users still set up in Q-Assist.

Settings reference

Everything a customer admin can change lives on one Settings tab in the Q-Assist app, behind FAS_Settings. Nothing here needs a deploy.

Settings are stored where they are read: values only Apex uses (country code, retention, record linking) are custom metadata in the org; values Q-Assist's servers enforce (licences, file limits, hours) are stored in Q-Assist and edited through Salesforce. Q-Assist accepts only known settings with validated values.

Data model

Every WhatsApp message is an ordinary Salesforce record, so partners can report on it, trigger automation from it and build on it. All Q-Assist metadata carries the FAS_ prefix to avoid collisions with the customer's own schema.

Built for partners to extend

• Lookups reserved for your automation. FAS_Conversation__c has FAS_Lead__c, FAS_Contact__c, FAS_Account__c and FAS_Opportunity__c. Q-Assist never writes them, so customer automation can set them without fighting the sync.
• Messages are safe to trigger on. Each message has a unique, case-sensitive external ID, and syncs are upserts, so a retried sync never creates a duplicate.
• Synced fields are read-only to reps because the next sync would overwrite an edit.
• Reference implementation: WhatsApp enquiries to Lead queues. We supply example Apex (no Flows) and a setup guide that turns a message from an unknown number into a Lead owned by a queue, chosen per business number, and links existing Contacts and Leads instead of duplicating them. It is deployed and owned by the customer, so partners can adapt it.

Implementing it in a customer org

Q-Assist installs and connects the app; the partner configures it for the customer's processes and builds anything around it. A typical rollout:

1. WhatsApp numbers (Q-Assist). Register each business number with Meta and connect it to Q-Assist. Physical SIMs are recommended; Meta has banned virtual numbers on arrival.
2. Deploy (Q-Assist). The Salesforce metadata is deployed into the org directly. There is no AppExchange package and no namespace; everything is FAS_-prefixed. Enterprise Edition or above is required.
3. Connect (Q-Assist, with the customer's admin). Create an integration user and give it FAS_Integration_User. Q-Assist sets up the server-to-server connection both ways and issues the org its own key.
4. Assign permission sets (partner). FAS_Base to reps, FAS_Manager to anyone who uses the inbox, FAS_Settings to Q-Assist admins, FAS_All_Conversations to managers. Permission set groups work well here.
5. Configure Settings (partner). Licensed users, business numbers and who works each one, record linking for every object the chat should appear on, shared files and quick replies, business hours and auto-replies.
6. Place the chat (partner). In Lightning App Builder, drop the Q-Assist chat component on the record pages that need it. On an object with no phone mapping it shows a clear message instead of failing.
7. Schedule jobs (partner). From Settings → Health, schedule the send-retry sweeper and the nightly file retention job.
8. Extend (partner, optional). Lead routing by number, linking conversations to Accounts or Opportunities, reports and dashboards on messages, notifications.

Updates to the Salesforce side are deployed by Q-Assist. Customer Settings are kept across updates.

Security and limits

Security and data

• Each org has its own key, stored by Q-Assist only as a hash. The org never tells Q-Assist which customer it is; Q-Assist works that out from the key, so one org cannot reach another's data. This has been tested with a second tenant.
• Q-Assist signs in to Salesforce with a certificate (OAuth JWT bearer). No passwords or refresh tokens are stored.
• Customer files are never on a public link. They are either copied into Salesforce Files or opened through a link that expires in 15 minutes.
• Data residency. Q-Assist runs in South Africa. Message content is copied into the customer's Salesforce org, which may be hosted elsewhere. Under POPIA that is a cross-border transfer the customer's agreement should cover.

Limits to plan for