> ## Documentation Index > Fetch the complete documentation index at: https://docs.ycloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Business and commerce policies > Check messaging, content, commerce, privacy, and industry requirements before launching a WhatsApp use case. 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 | Policy area | What to assess | | - | - | | Business Messaging Policy | Identity, expected communications, consent, automation, and acceptable use. | | Commerce requirements | Products and services offered through catalogs or other commerce experiences. | | Business terms and messaging guidelines | Responsibilities when using WhatsApp Business services. | | Privacy and applicable law | Collection, use, sharing, protection, and retention of customer data. | Use the current [WhatsApp Business Messaging Policy](https://business.whatsapp.com/policy), [Business Terms of Service](https://www.whatsapp.com/legal/business-terms/), and [Messaging Guidelines](https://www.whatsapp.com/legal/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: | Area | Evidence to prepare | Stop the launch when... | | - | - | - | | Business identity | Profile, website, legal business/brand relationship. | The sender presents a misleading identity. | | Recipient expectations | Consent wording, source, scope, and current preferences. | The audience source cannot establish relevant permission. | | Message content | Template, samples, final variables, and button destinations. | A reviewed template is being repurposed to hide a different use case. | | Product or service | Catalog items, offer terms, recipient market, and relevant licenses. | The proposed activity is prohibited or an exception has not been established. | | Customer data | Fields collected, destination systems, access, and retention. | Sensitive data is collected without a justified need and protection plan. | | Automation and support | Escalation path, failure handling, and out-of-hours response. | A customer cannot get appropriate help or stop the workflow. | | Monitoring | Delivery errors, complaints, opt-outs, and an incident owner. | Nobody can detect and contain a harmful send. | ### 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](/en/documentation/whatsapp-business-platform/consent-policies-and-account-health/account-restrictions-and-appeals). ## Related topics * [Customer opt-in](/en/documentation/whatsapp-business-platform/consent-policies-and-account-health/customer-opt-in) * [Customer opt-out](/en/documentation/whatsapp-business-platform/consent-policies-and-account-health/customer-opt-out) * [Catalogs and commerce](/en/documentation/whatsapp-business-platform/more-whatsapp-features/catalogs-and-commerce) * [WhatsApp Flows](/en/documentation/whatsapp-business-platform/more-whatsapp-features/whatsapp-flows/index) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.