Skip to main content
Before launching a WhatsApp workflow, check both how you contact customers and what your business offers. Customer consent, template approval, business verification, and payment of fees are separate requirements. None is a blanket approval for the entire use case.

​
Start with the applicable policies

Use the current WhatsApp Business Messaging Policy, Business Terms of Service, and Messaging Guidelines. Follow the commerce-policy references within the Business Messaging Policy when selling or facilitating transactions. This page is a product-planning guide, not jurisdiction-specific legal advice.

​
Review the complete customer experience

Assess the message, business profile, product, button destination, and downstream workflow together. Recommended review questions:
  • Does the business identity match what customers expect?
  • Is the customer authorized to receive this communication?
  • Does the actual offer match the approved template’s purpose?
  • Is the landing page accurate and consistent with the message?
  • Can the customer reach support and stop future messages?
  • Is unnecessary sensitive information exposed?
Do not assume that passing a template review means Meta has approved every future value inserted into its variables or every product on the linked site.

​
Regulated and restricted activities

Rules vary by activity, country, age, and product surface. Some regulated-sector messaging has limited exceptions with additional requirements. An exception for messaging is not automatically permission to sell through a catalog or payment experience. Before building a regulated use case, document the exact products, recipient markets, age controls, licenses, and approvals that apply. Obtain qualified advice where needed. Do not copy an allowed-country list from an old tutorial or infer permission from a competitor’s example. Review the current policy sections for your specific activity.

​
Protect customer information

Collect only the data needed for the task and explain its use. Set access and retention rules for Inbox conversations, Flow submissions, exports, and connected systems. Avoid asking customers to send full sensitive identifiers through a chat when the task can use a safer method. Use synthetic data in testing and redact customer content from general troubleshooting logs. A Flow or automated agent does not remove your responsibility for how the submitted data is used.

​
Provide an escalation route

Automation should include a clear path to help when it cannot resolve a request. Depending on the workflow, that may be a human handoff or another supported contact channel. Test failed recognition, repeated questions, unavailable agents, and out-of-hours requests. Do not trap the customer in an automated loop.

​
Use a launch review matrix

Assign an owner and evidence to each question:

​
An example boundary: service discussion versus a sale

A customer-support conversation, a promotional offer, a catalog listing, and a payment flow can be governed differently even when they concern the same industry. Do not carry permission from one surface into all the others. For a regulated use case, write down the exact activity: “send a non-promotional update about an existing service” is more precise than “finance messages.” Then assess the applicable policy section, market, age requirements, and any required authorization. Customer consent does not waive platform rules, and platform availability does not settle local legal requirements. When the rules are unclear, resolve the use case before building an automated campaign.

​
Data minimization in practice

For an appointment Flow, collect the information needed to arrange the appointment. Avoid adding unrelated identity, financial, or health fields merely because the form supports them. Confirm where completed submissions will be stored and who can see them. In troubleshooting screenshots, mask customer phone numbers, private message content, credentials, and unrelated account details. Use fictional records in public documentation.

​
Keep a launch record

For each new use case, record its owner, audience, consent source, template category, applicable policies, data flow, and support route. Revisit the record when you introduce a new product, market, template purpose, or data collection field—not only when a restriction occurs. If Meta flags an issue, use Account restrictions and appeals.