01What this guide helps you do
Guide customers through the available collection route and inspect the resulting record.
This guide focuses on one task within permission & opt-outs. Its completion test is specific: The response is connected to the intended contact and purpose. Use that result to decide whether the task is finished. Opening a page, entering a value or seeing a brief notification can be part of the process without establishing the complete result.
02When to use this workflow
Use this workflow when your immediate goal is to use a permission collection link. Keep the scope limited to the relevant permission record. If you are solving a different problem, use the related guides at the end rather than applying every action here to unrelated records.
The usual operational owner is the person accountable for the permission evidence. If another person owns the relevant business facts or permissions, involve that person before changing the shared record. Individual access and business authority are not always the same thing.
03Prepare the information you need
Start from permission or a withdrawal the business has actually received. Identify the intended communication purpose and the source of the decision. Prepare a concise evidence reference, an accurate date and the correct contact selection. Bulk recording is suitable when the same supported decision genuinely applies to the selected records; a large upload is not a reason to invent a shared permission history.
Collection link, intended contacts, current wording.
04Find the right workspace and feature
Start from Contacts → WhatsApp permission. Treat this as a feature locator: the arrangement of menus can differ between the web interface and the native application. Confirm the workspace name and the relevant record before proceeding, especially if you manage more than one business or use both India and UK accounts.
The target of this task is a permission record. Keep its identity visible while you work. A similarly named record or a previously open browser tab can otherwise make a correct action affect the wrong context.
05Understand the information on screen
| Information | What it means | Practical check |
|---|---|---|
| Decision | Received or withdrawn | Check the selected meaning |
| Source | Where the decision was obtained | Use a specific understandable label |
| Evidence | Reference to supporting context | Avoid unnecessary sensitive content |
| Date | When the decision occurred | Use an accurate supported date |
Apply these distinctions to the specific inputs for this guide: collection link, intended contacts, current wording. You do not need to collect every possible field in the workspace. Use the information needed to make this decision and to verify its result.
06Inspect the current state first
Read the decision label carefully. Permission received and permission withdrawn have opposite effects even if both produce a successful save notification. Review the contact's current state and any relevant previous decision. Keep a source such as a form, phone conversation or customer request understandable, but do not paste sensitive evidence into a field that only needs a reference to an authorised record.
If the intended result is already present, check whether any further action is necessary. This is particularly useful after an interrupted session or when another teammate may have completed part of the work.
07Step 1: Review the link's public wording
Begin with the relevant inputs: collection link, intended contacts, current wording. Resolve any ambiguity that would change which record or business decision the task concerns. Keep a short note of the original state if you will need to compare it later. This creates a clear starting point for the next action instead of relying on memory after several screens have changed.
09Step 3: Check the recorded response
Finish by checking the observable result, not only whether the interface accepted an interaction. If the result is still pending or cannot be verified, preserve that distinction in your notes. A clearly recorded unresolved state is more useful than announcing completion and discovering the missing part during a live customer task. Use the verification guidance below for the relevant feature.
10Explain the choice before sharing the collection route
Use the available permission-link workflow to give a customer a clear way to record a choice. Review the business identity and the communication purpose shown to the person. Share the link through a route appropriate to the existing customer relationship; a collection link is not permission to send an unsolicited campaign asking for permission.
After a controlled submission, inspect the resulting contact decision and evidence context. Check both received and withdrawal behaviour where the flow provides those choices. Keep the link associated with the intended workspace so a successful submission is not mistakenly attributed to another business account.
| Check | Meaning for this task |
|---|---|
| Before sharing | Review identity and purpose |
| After submission | Inspect the actual stored choice |
| Before a campaign | Refresh current recipient eligibility |
11Worked example
A customer follows the business's permission link and the team verifies the resulting status.
The useful lesson is the sequence of decisions, not a promised result for every business. In this scenario, begin with “Review the link's public wording”, continue with “Share it through an appropriate channel”, and finish with “Check the recorded response”. Compare the result with the completion test before applying the same process to a wider set of records.
Use invented names and references when practising this example. Keep the structure realistic, but do not copy a live customer conversation or payment record into training material simply to make the demonstration look authentic.
12Verify the result
After saving, inspect the contact's displayed decision and compare it with the choice you intended. Then refresh the relevant campaign audience to see the current eligibility result. These checks test persistence and downstream use separately. If a contact remains unconfirmed, look at the actual saved decision and any validation error before assuming that Meta must confirm a permission record for you.
The response is connected to the intended contact and purpose.
13Decide what to do next
| What you observe | Appropriate next step | What to avoid |
|---|---|---|
| The expected result is visibly present. | Keep the result and continue with the intended business task. | Repeating a completed action without a reason. |
| The result is still pending or uncertain. | Review the current permission record and the relevant status. | Calling the task complete without evidence. |
| The result conflicts with the intended choice. | Revisit: Share it through an appropriate channel. | Changing unrelated records to hide the symptom. |
Use the observed state to choose a branch. A recovery action should address the actual cause and preserve any work that is already correct. If several people are involved, make the next owner explicit so a pending state does not become an unattended task.
14The main mistake to avoid
Generating a link does not mean the customer has completed it.
This mistake can make the task appear finished while leaving the business outcome unresolved. Return to the inputs and the named steps when the result is unclear. Keep a useful distinction between what you observed and what you expected. If a weaker signal is all that is available, describe the remaining uncertainty and identify how it can be checked.
15Diagnose an unexpected result
Compare the expected result with the exact current state of the permission record. Record which of the three actions was last completed and what happened next. Keep the exact validation message or visible status where one exists. This separates an input problem from a saved-state problem and helps another person reproduce the same example.
Check the workspace, selected record and current view. Change one relevant factor at a time. If you change several unrelated settings together, a later success may not explain which change actually resolved the issue.
16Recover without duplicating work
Correct an inaccurate decision only on the basis of verified evidence. Preserve enough context to explain why the correction was made. If a bulk update is interrupted, inspect the result and a sample of the selected contacts before repeating it. A withdrawal received outside WhatsApp still needs the business's operational attention; do not wait for a provider API to discover every off-platform customer request.
If the result depends on a provider or another authorised person, record that dependency and use the appropriate route. Do not simulate success by manually changing an unrelated display value or by removing evidence of the original outcome.
17Use the workflow on web and mobile
On mobile, review the decision dropdown after selecting it and before pressing save. Check that the keyboard or scroll position has not hidden the date or evidence field. A confirmation notification reports that an operation happened; the contact record tells you what decision was actually stored. Compare that record across devices using the same account and refreshed view.
When comparing devices, match the same account, record and relevant filters. A desktop screenshot and a mobile screen from different contexts are not evidence of inconsistent data. If a layout problem prevents completing the task, report the screen name, device context and the affected control with private details removed.
18Keep a useful operational record
Retain only the information needed to explain the task: its purpose, the relevant permission record, the action taken and the observed result. If the operation produced a safe reference, keep it with the time and workspace context. This makes a later handover or support query more precise than a screenshot with no explanation.
| Record | Useful content |
|---|---|
| Purpose | Guide customers through the available collection route and inspect the resulting record. |
| Inputs reviewed | Collection link, intended contacts, current wording |
| Outcome to verify | The response is connected to the intended contact and purpose. |
| Next owner | Person accountable for the permission evidence |
19Protect private information
Use the minimum customer or business information needed for the task. Restrict access to authorised colleagues, and redact unrelated names, numbers and message content when sharing a screenshot. An evidence reference is often more suitable than copying the underlying private document into a general field or support message.
For this workflow, the useful input categories are collection link, intended contacts, current wording. They should help you make and verify the decision; they are not a reason to publish a customer database, credentials or internal operating notes. The fictional example in this guide can be used for training without exposing live records.
20Know the limits of this workflow
A permission record describes evidence your business holds. It is not a Meta-issued certificate and does not override a withdrawal or a provider restriction.
Keep the decision, date, source and evidence together. Use a bulk record only when the same evidence actually covers the selected people.
Read the linked source material for decisions controlled by a provider or by the applicable commercial terms. A practical guide explains how to approach the task; it does not add a new contractual guarantee or establish that every business use is legally suitable. Use the responsible business owner for unresolved exceptions.
21Review the process over time
Permission records should remain connected to their original purpose and collection context. Review them when the purpose changes, when a customer withdraws or when contradictory evidence appears. Keep withdrawal handling accessible to the team receiving calls, emails and messages. A periodic sample review is more useful than assuming that every imported decision was mapped correctly just because the overall import completed.
Update related instructions when the underlying business fact or product behaviour changes. Keep a representative example from this workflow so a future revision can be compared with an explicit expectation rather than judged from memory.
22Practical questions
What should I check before starting?
Prepare collection link, intended contacts, current wording. Then confirm the workspace and the relevant permission record. The first action is “Review the link's public wording”. Starting there keeps later decisions grounded in the correct record and avoids trying to solve a different problem with this workflow.
How do I know the task is complete?
Use this observable test: The response is connected to the intended contact and purpose. If a state is pending, describe it as pending. If a save or provider operation is uncertain, inspect the current record before repeating it. The result matters more than whether a button was pressed.
What if the result still does not match?
Review this risk first: Generating a link does not mean the customer has completed it. Keep the exact symptom, the relevant reference and the last completed action. Ask the person accountable for the permission evidence or the appropriate support route to review the remaining issue, using a small reproducible example rather than a broad export of customer data.
23Completion checklist
Use this checklist as a final review of the task, not as a substitute for the steps above. If an item remains unresolved, identify the next action and its owner. Do not mark a provider-dependent or unverified result complete merely because the rest of the checklist is finished.
- The intended workspace and permission record were identified.
- The necessary inputs were reviewed: collection link, intended contacts, current wording.
- Review the link's public wording.
- Share it through an appropriate channel.
- Check the recorded response.
- The result was checked: The response is connected to the intended contact and purpose.
- The task-specific risk was considered: Generating a link does not mean the customer has completed it.
- Any unresolved issue has an accountable next owner and a useful evidence reference.