Britixo WhatsApp Enterprise: complete how-to guide

Complete r26.0 operating manual for installation, QR accounts, permissions, Inbox, messages, customer verification, visitor leads, CRM services, OTP, Help Centre responses, portal history, audit, durable delivery, offline workers and security. The guide then takes you through the correct route, the checks to complete before making changes, the workflow in order, and the evidence to review afterwards.

What the module provides

Britixo WhatsApp Enterprise embeds a permission-scoped, multi-account WhatsApp Web workspace inside the CRM. Each linked number has its own account identity, encrypted credentials, private runtime, event cursor, LocalAuth session and access matrix. Staff can work from the CRM Inbox while automated workflows continue without an open browser or signed-in administrator session.

Access model and visible menus

Access is enforced in two layers. A native module capability controls whether a staff member may use a class of feature, and the per-account matrix controls what that person may do on each WhatsApp number.

1. Go to staff roles and permissions and grant only the native capabilities required.
2. Go to WhatsApp → Access Control.
3. For each active staff member and account, grant View, Reply, Convert and Manage independently.
4. Save the matrix, then test with that staff account. The header unread badge, account selector, assignment lists, media and customer-history visibility should reflect the saved scope.

Install, activate and verify r26.0

The module uses its own portable install.php and prefix-safe schema. Activation creates or upgrades sixteen module-owned tables and adds the current settings without deleting existing operational data.

1. Keep a controlled copy of the currently installed module package and confirm the CRM supports normal module installation.
2. Upload the supplied archive through the CRM module installer, following Upload and activate the module.
3. Activate Britixo WhatsApp Enterprise. Allow the installer to create or upgrade the module-owned schema.
4. Go to WhatsApp → Connections. A new or existing account must enter the managed preparation flow rather than exposing Node, port or token fields.
5. Complete the post-activation verification: menu visibility, schema state, account preparation, QR/connected readiness, Inbox, queue, worker health and audit.

Create and link a WhatsApp account

1. Go to Admin Area → WhatsApp → Connections.
2. Enter a descriptive account name, up to 191 characters, and choose whether the account is Active.
3. Create the account. The module generates the account key, encrypted connector token, encrypted wake credential, private loopback port and isolated session/runtime paths.
4. Wait for automatic preparation. Readiness requires a usable runtime, a real headless-browser launch, authenticated loopback status, QR or connected state, a healthy supervisor/scheduler and a successful browser-independent CRM worker pass.
5. On the phone, open WhatsApp → Linked devices → Link a device, then scan the live QR shown for that exact account.
6. Wait for Connected. The connector imports the bounded recent history window and begins live event processing.
7. Go to Inbox, select the new account and confirm conversations, unread state and message direction.

Repair, restart, unlink and delete safely

These actions are deliberately different. Choose the least disruptive action that matches the fault.

1. Use Connect/repair first for a runtime preparation fault.
2. Use Restart for a healthy retained session that needs process recovery.
3. Use Sync history for bounded reconciliation.
4. Use Unlink only when you intend to invalidate that linked device.
5. Use Delete only when the account must leave operational use. If runtime removal fails, the model fails safe and does not partially change the account record.

Operate the multi-account Inbox

1. Go to WhatsApp → Inbox.
2. Use the account selector to switch numbers. The selected numeric account ID is retained for that staff member, but every request revalidates server-side permission.
3. Search by conversation/contact text and combine it with All, Open, Pending or Closed status.
4. Enable Unread only when you need conversations with current unread messages.
5. Go to a conversation. Older messages are loaded in bounded pages; stale responses from a previously selected account are discarded.
6. Use Sync now only when you need a controlled recent-history reconciliation. Live events continue through the authenticated shared long-poll and fallback refresh.

Send messages, attachments and read acknowledgements

1. Go to the intended conversation and verify the selected account before replying.
2. Enter up to 10,000 characters and use Send, or choose a permitted file.
3. For files, follow Send an attachment. The configured maximum is 1–32 MB; the default is 8 MB.
4. The message enters the durable outbound queue. When capacity is available it is immediately eligible for the conversation’s existing account.
5. Check direction, timestamp and delivery acknowledgement. Internal staff attribution is retained separately from customer-visible content.
6. When opening an unread conversation, the module calls WhatsApp’s authenticated seen operation before applying the local read change; see Mark as read.

Control status, assignment, priority and tags

1. Go to conversation controls in the selected conversation.
2. Set status to Open, Pending or Closed.
3. Assign an eligible staff member or remove the assignment.
4. Set priority to Low, Normal, High or Urgent.
5. Add validated tags or remove existing tags.
6. Save and verify the conversation list reflects the new controls without changing another account’s conversation.

Create and use Standard Replies

1. Go to WhatsApp → Standard Replies.
2. Enter a title, optional slash shortcut, optional category and the reply body.
3. Select Global only if you are an administrator and the text should apply across authorised accounts; otherwise select one account.
4. Select All authorised staff or Selected staff. If Selected, tick the permitted staff members.
5. Set sort order and Active/Inactive, then save.
6. In Inbox, insert the reply through the standard reply picker or its shortcut, review the text and send it through the normal queue.

Create native CRM records manually

Manual conversion remains available independently of automated customer workflows. It requires Convert access to the selected account and uses native CRM models rather than creating parallel records.

Understand all customer verification routes

r26.0 contains two deliberate registered-customer verification patterns plus a visitor route. The active route depends on whether Contact entry is enabled and whether the number already has a unique registered-mobile match.

Route A — unique registered mobile

1. An inbound one-to-one message is normalised and compared with active customer contact telephone values.
2. Exactly one active contact match verifies the conversation automatically when Registered mobile recognition is enabled.
3. The module links the conversation to the customer/contact, records the verification evidence and sends the registered-number welcome/service continuation.
4. Ambiguous matches are not automatically assigned.

Route B — configurable registered contact entry

1. An unknown contact receives the welcome and chooses option 1 / registered customer. Accepted wording includes “registered”, “registered customer”, “customer” and “client”.
2. The customer supplies an exact active contact email address.
3. The CRM emails a cryptographically generated six-digit code; only its password hash is retained.
4. The customer replies with the code before the configured 2–15 minute expiry and within the configured 3–10 attempt limit.
5. RESEND is available after the configured 15–300 second cooldown; CHANGE EMAIL restarts the email step.
6. On success the conversation is securely linked. The contact telephone is updated only when the canonical number is genuinely different.

Route C — legacy registered email plus customer account number

1. When the older verification session applies, the contact supplies the exact active registered email.
2. The module asks for the six-digit customer account number, or accepts EMAIL to send that number to the registered address once for the session.
3. A matching number verifies the customer. Repeated failure reaches manual review after the configured maximum attempts.
4. Account numbers are generated and managed by the module’s client-account service; raw verification replies are not copied into audit context.

Route registered customers and visitors professionally

Contact entry is the controlled first-response workflow for a new unknown or ambiguous one-to-one contact. The first reply is immediately eligible and all routes share the aggregate delivery ceiling.

Registered customer route

Visitor route

1. The contact chooses option 2 / not registered. Accepted wording includes “not registered”, “non registered”, “visitor”, “new customer” and “new”.
2. Collect full name.
3. Collect the callback telephone number, including country code, or accept SAME to use the WhatsApp number.
4. Collect email and send the same protected six-digit email-code challenge.
5. After email verification, collect the callback reason/message.
6. Create one native CRM Lead using the configured source/status, or the first valid available values when set to zero.
7. Return the Lead reference. The pending visitor payload is encrypted while the workflow is incomplete.

Configure verified-customer service automation

After a verified match, the service menu presents only enabled branches. Customers may answer by number or recognised wording. MENU reopens the menu after a completed branch.

Enable built-in and custom CRM self-service

The CRM Services tab discovers providers only when the required native tables and fields exist. Every query is read-only and restricted to the verified customer account.

Custom numbered menu options

1. Go to Settings → CRM services.
2. Enable the validated providers that may appear.
3. Add as many custom menu rows as needed.
4. Select a validated service provider for each row and write the customer-facing label, for example “Check your application progress”.
5. Save. The next available menu number is assigned automatically; selecting a provider in a custom row also enables that service.
6. Test with a verified customer that has and does not have records, confirming the result remains ownership scoped.

Use both registration OTP modes correctly

Verified-customer service-menu OTP

1. Enable Settings → Registration OTP and set expiry to 2–15 minutes and attempts to 3–10.
2. Keep Registration verification code enabled in the verified service menu.
3. A verified customer chooses the option. The module queues a six-digit code with OTP priority, stores only its password hash and binds it to the current session.
4. The customer replies with the code. Success emits the authorised registration-OTP verified event; expiry, attempt exhaustion and success all make the challenge unusable.

New customer self-registration gate

1. Separately enable Setup → Settings → Customers → Verify new customer registrations through WhatsApp.
2. The save action performs a live readiness check: current schema, linked account, detached supervisor and a fresh browser-independent scheduler worker pass.
3. When both this customer setting and the Registration OTP master switch are enabled, a newly self-registered contact receives a six-digit code at the registered WhatsApp number.
4. The registration page shows WhatsApp verification as step 1. After success, the module invokes the CRM’s normal verification-email model and sends the contact to the existing email-verification step 2.
5. Existing customers, administrator-created contacts, staff sessions and unrelated email templates retain their normal behaviour. Disabling the Customers setting restores the default registration flow.

Connect a client-specific Help Centre

1. Go to Settings → Help Centre.
2. Enable the feature and enter the public HTTPS directory URL for the client’s Help Centre.
3. The source must expose assets/search-index.js and help-centre-manifest.json at the expected paths.
4. Save. The module validates and synchronises the index; an unsafe or invalid source is rejected without replacing the previous active source.
5. Set the service-menu label and customise the question prompt, matched response and no-match response.
6. Test a verified customer query. A match returns one article URL plus the related category URL; a low-confidence result returns the full Help Centre URL.

Complete administrator settings reference

General

Verification

Contact entry

Automation and delivery

CRM Services, Registration OTP and Help Centre

Every editable customer-facing template

Templates change wording only; they do not disable validation, remove identity checks, change the queue or create an unsupported branch. Each field accepts up to 4,000 characters in the current view.

Core verification and automation templates

• Initial registered-email prompt
• Invalid email-format response
• Registered email not matched response
• Matched-email account-number prompt
• Invalid or unmatched account-number response
• Account-number email sent response
• Repeated account-number email request response
• Account-number email failure response
• Manual-review response
• Successful verification response
• Registered-number and continuation welcome ({{company_name}}, {{client_name}})
• Service-menu introduction ({{contact_name}})
• Invalid menu choice response
• Open-ticket duplicate response ({reference})
• Simultaneous-request response
• Support-ticket subject prompt
• Support-ticket details prompt
• Callback reason prompt
• Callback date/time/timezone prompt
• Team hand-off details prompt
• Support-ticket confirmation ({reference})
• Callback confirmation ({reference})
• Team hand-off confirmation
• Automatic-action failure response

Contact-entry templates

• Welcome introduction ({{company_name}})
• Option 1 label
• Option 2 label
• Invalid option response
• Registered email prompt
• Registered email not verified
• Email-code sent response ({{masked_email}}, {{minutes}})
• Email-code resend cooldown ({{seconds}})
• Email transport rejection response
• Invalid email-code response
• Expired / attempts-exhausted response
• Registered verification success ({{client_name}}, {{company_name}})
• Visitor full-name prompt
• Visitor callback-number prompt
• Visitor email prompt
• Visitor callback-reason prompt
• Visitor lead confirmation ({reference})
• Contact-entry failure response

Help Centre templates

• Question prompt.
• Matched response using {{article_title}}, {{article_url}}, {{category_name}} and {{category_url}}.
• No close match response using {{help_centre_url}}.

Registration code wording

• Verified-customer OTP message using {{code}} and {{minutes}}.
• Invalid, expired/attempts-exhausted and successful OTP responses.
• New customer registration OTP message using {{company_name}}, {{code}} and {{minutes}}.

Use protected customer and administrator history

Review audit, verification and compliance evidence

1. Go to WhatsApp → Audit Trail.
2. Filter by account, staff member and action text.
3. Check general audit rows for connection transitions, access changes, sends, read actions, history, files, CRM conversions, portal/customer history and account lifecycle.
4. Check verification sessions/events for route, state, actor and outcome.
5. Use account-scoped evidence to diagnose a workflow; do not rely on raw server logs as the normal user-facing record.

Understand exactly-once delivery and offline operation

Every staff and automated outbound message enters one module-owned queue before connector delivery. The queue, connector and worker use layered references and locks so retries do not knowingly transmit a second message.

Always-on runtime

• One lightweight user-space supervisor per account owns an exclusive mode-0600 lease and independently supervises connector and scheduler children.
• The scheduler watches protected event/wake state every 200 ms and supplies a CRM worker pass at least once per second.
• A matching PHP CLI is preferred only after a bounded, read-only tenant/account/credential probe succeeds.
• Deterministic CLI failure falls through to certificate-validated HTTPS in the same pass; an uncertain timeout is not replayed immediately because that could duplicate a send.
• The same-host local virtual HTTPS route is attempted before public HTTPS when no verified matching CLI is available.
• On Linux, the live supervisor launches children through /proc/self/exe so a private runtime path refresh cannot strand a still-running supervisor.
• The connector and scheduler use a crash-recoverable account lock, event cursor, queue lock and reference identity as exactly-once authorities.
• Browser closure, CRM logout and an absent administrator session do not stop normal automation. Hosting process policy, WhatsApp availability, the rolling limit and CRM/PHP latency can still affect delivery time.

Security and privacy controls

• Connector services bind to loopback only and require the matching high-entropy bearer token and account key.
• Connector tokens and account-specific wake credentials are encrypted independently; the public worker accepts only PUT with both matching credentials and timing-safe comparison.
• No unauthenticated public webhook or CSRF exclusion is introduced for connector events.
• Runtime roots receive deny-all web protection; credentials and health state use restrictive permissions and are not passed in command-line arguments.
• Tenant/account namespaces isolate SaaS master, tenants and linked numbers that share one application filesystem.
• LocalAuth sessions and runtime data are outside the replaceable module directory.
• Private Node downloads use HTTPS and a pinned archive checksum; npm dependencies come from the committed lockfile and the bundled Chromium must pass a real headless launch.
• Private runtime refresh uses a staged prior-directory swap and restores the prior executable tree if the replacement cannot run.
• Media is MIME allow-listed, size-limited, randomly named and controller served.
• Verification codes are cryptographically generated, stored as hashes and never copied into normal audit context.
• Customer self-service queries are ownership scoped and read-only.
• Explicit UNLINK and DELETE confirmations protect destructive account actions.

Professional troubleshooting sequence

1. Reproduce on one account and one controlled conversation.
2. Record the visible account state, exact action and time.
3. Check Access Control and active account state.
4. Check Audit Trail and verification events.
5. For runtime faults, use Connections → Connect/repair or Restart; never delete LocalAuth/runtime files manually.
6. For data or automation faults, verify queue/session state and the native CRM prerequisite.
7. After correction, run the final production verification checklist across two accounts and differently scoped staff.

Feature coverage and existing detailed articles

This master guide links to the complete existing article library. Use the topic pages below for smaller task-specific instructions. Their r20.5 build labels remain preserved where they describe the original documented baseline; r26.0 additions and changed boundaries are authoritative in this guide.

r21.0 to r26.0 additions covered here

Continue with related guidance