WhatsApp approval queue

This guide builds a queue of requests that a person approves or rejects from their own WhatsApp. Customers submit requests in one flow; each request is saved and the approver is notified; the approver opens a list of everything still pending, picks a case, decides, and goes back to the list until it is empty.

It uses nodes that each have their own page: Packages to keep the requests and the decisions, Notify a third party to reach the approver, a Python Executor to work out what is pending, and Interactive Options with options from a list variable to show it.

Why a Queue

Notify a third party on its own handles one case at a time per person. A second notification to the same approver while the first is still pending replaces it, and the first case can no longer be reached from that tap. With two customers submitting a minute apart, the approver would only ever see the second one.

So the notification does not carry the case. It only tells the approver there is something to review, and the approval flow reads the queue itself, every time, from where the requests are stored.

Why a Decisions Package

A package cannot be updated or marked as done. Every time a flow stores a package, a new one is created next to the previous ones; nothing changes the request once it is saved. To record that a request was decided, the approval flow stores another package, a decision, with the same identifier as the request.

A request is then pending when it has no decision stored after it. That rule also covers a customer who submits again after a rejection: the new request is later than the old decision, so it shows up as pending again.

The Pieces

Step 1: The Template

Create a template in Templates with a quick reply button and assign the approval flow to that button. A body such as "There is a new request from {{1}} waiting for your review" is enough; the template does not need to describe the case, because the approver will see the whole list. Assign the template its WhatsApp connector, and wait for Meta to approve it.

Step 2: The Customer Flow

After the nodes that collect the request:

1. Packages, Store mode. Package key APPROVAL_REQUEST. Alias: the case identifier, for example {{tax_id}}. It must be unique per case and the same every time the same case is submitted, because it is what ties a decision to its request. JSON fields: name (the customer's or company's name), amount, product, and whatever else the approver needs to see.
2. Notify a third party. The template from step 1, the approver's number (a Fixed number is the usual choice), and a value for each template variable, for example the customer's name for {{1}}. You do not need to pass the case under Variables for the target flow: the approval flow reads the queue.
3. Message. Tell the customer their request is under review.

Connect the Error output of the Notify node too. A request that was stored but whose notification failed is still in the queue, and it will appear the next time the approver opens the list; the notice on the conversation tells you why the notification did not go out.

Step 3: The Approval Flow

This flow starts when the approver taps the template button, in the approver's own conversation.

1. Set Variable. offset, number, literal 0.
2. Packages, Read mode. Key being searched: APPROVAL_REQUEST. Clear the Customer field, which comes with {{borrower_id}} by default: the approver's conversation is not the customer's, and the queue has to include every customer's requests. List of packages, newest first, at most 50. Result into requests (array).
3. Packages, Read mode. The same, with key APPROVAL_DECISION and the result into decisions (array).
4. Python Executor. Input variables: requests, decisions and offset, with those same keys. Output variable: queue. The code is below.
5. Set Variable. Three variables from the result: pending (array) from queue.pending, total (number) from queue.total, next_offset (number) from queue.next. The extraction is needed because the list selector of Interactive Options only offers array variables.
6. Interactive Options, with Options source set to From a list variable:
   • Body: something like "You have {{total}} pending requests. Pick one to review it."
   • List button text: Requests.
   • Variable with the list: pending.
   • Title field: name. Description field: detail. Identifier field: leave it empty; the elements already carry an id.
   • Variable for the id of the chosen row: case_id. Variable for the text of the chosen row: case_name.
7. From Chosen option, a second Interactive Options with fixed options: "{{case_name}}: approve or reject?", with the options Approve and Reject. Turn on Also save the option key, give the options the keys approved and rejected, and save the key into decision. Both options lead to the next node.
8. Packages, Store mode. Package key APPROVAL_DECISION, alias {{case_id}}, JSON field decision from the decision variable. Then connect it back to step 1, so the list is read again from the first page, without the case just decided.
9. From See more, a Set Variable that sets offset to the value of next_offset, connected back to step 2.
10. From No match, a Conditional on total equal to 0. When it is, a Message ("There are no pending requests") and a Close Conversation. When it is not, the approver typed something that is not in the list: go back to step 2 and show it again.

Connect the Error output of the list, too: it fires when WhatsApp refuses to send it.

The Pending Computation

def execute(input_data, context):
    import json
 
    def as_list(value):
        if isinstance(value, str):
            try:
                value = json.loads(value)
            except ValueError:
                return []
        return value if isinstance(value, list) else []
 
    decided_at = {}
    for decision in as_list(input_data.get("decisions")):
        case_id = decision.get("alias") if isinstance(decision, dict) else None
        if case_id:
            decided_at[case_id] = max(decided_at.get(case_id, ""), decision.get("createdAt") or "")
 
    pending, seen = [], set()
    for request in as_list(input_data.get("requests")):
        if not isinstance(request, dict):
            continue
        case_id = request.get("alias")
        if not case_id or case_id in seen:
            continue
        seen.add(case_id)
        if (request.get("createdAt") or "") <= decided_at.get(case_id, ""):
            continue
        content = request.get("content") or {}
        pending.append({
            "id": case_id,
            "name": content.get("name") or case_id,
            "detail": ("$" + str(content.get("amount") or "") + " - " + str(content.get("product") or ""))[:72],
        })
 
    try:
        offset = int(float(input_data.get("offset") or 0))
    except (TypeError, ValueError):
        offset = 0
    if offset < 0 or offset >= len(pending):
        offset = 0
    return {"pending": pending[offset:], "total": len(pending), "next": offset + 9}

What it does, in order:

• as_list accepts the read either as a list or as its JSON text, and treats anything else as empty.
• decided_at keeps, for each case identifier, the date of its latest decision.
• The loop over requests walks them newest first, which is the order the read returns, so the first request seen for an identifier is its latest one; older submissions of the same case are skipped. A request is pending when it is later than the latest decision of its case, or when the case has none.
• Each pending case becomes a row: id (the identifier, which the list uses to know which case was picked), name (the title) and detail (the description, cut to 72 characters, the WhatsApp limit, so the list does not have to cut it and warn).
• offset is where the page starts. A position that fell out of range, because other cases were decided in the meantime, goes back to the first page.
• The result is the page (pending, from the position onwards), the count of everything pending (total) and the next position (next).

Pages advance by nine because the list shows nine rows plus Ver más when it receives more than ten elements. The page returns everything from the position onwards, so the list always gets more than ten while there are more than ten left, and shows the rest in full on the last page.

Things to Know

The reads bring at most 50 packages each. Newest first, up to 50 requests and 50 decisions. The recipe holds as long as the last 50 requests and the last 50 decisions cover everything still open. For a busier queue, narrow each read (for example with a label per approver or per period) or move the computation to a workflow.

The list is checked against what was sent, not against the queue. If two people approve from the same queue, a case one of them decided can still be picked from the list the other one already has on screen. The second decision is stored as well, and the latest one wins, because it is the one with the later date. If a double decision matters, read the decisions again after the pick and check the case is still pending before storing.

The customer is not told the decision by this recipe. It records the decision. Telling the customer is a separate step that your process decides.

The Ver más row reads the same for everyone. Customers and approvers see Ver más, whatever the language of the editor; the output is called See more on the canvas.

Every write is a new package. Neither the requests nor the decisions are ever overwritten, so the packages of a case are also its history: when it was submitted, each time it was submitted again, and every decision taken on it.