Choosing the Right LINE Message UI: Confirm, Buttons, Quick Replies, Carousel, or Flex?

You are building a LINE customer flow and start with a confirm template.

Then the requirements grow:

Confirm
Cancel
Change address
Contact support

Enter fullscreen mode Exit fullscreen mode

At this point, the problem is no longer “How can I add more buttons to a confirm template?”

The real question is:

Which LINE message type matches the decision the user needs to make?

A LINE confirm template is intentionally limited to two actions. It is designed for one binary decision—not as a compact menu.

When the flow needs more choices, move to a buttons template, quick replies, a carousel, or a Flex Message instead of forcing the confirm component beyond its intended shape.

The short answer

LINE message surface Best for Main interaction limit Confirm template One binary decision Two actions Buttons template A compact card with several primary actions Up to four actions Quick replies A temporary next-step menu Up to 13 quick reply buttons Carousel template Browsing repeated items Multiple structured columns Flex Message Custom layouts and visual hierarchy Flexible JSON-based layout

A useful rule is:

Two choices      → Confirm
Three or four    → Buttons
Five to thirteen → Quick replies
Repeated items   → Carousel
Custom layout    → Flex Message

Enter fullscreen mode Exit fullscreen mode

The number of choices is not the only factor, but it is a good first filter.

What a confirm template is designed to do

A confirm template presents text followed by exactly two actions.

Typical examples include:

• Confirm or cancel
• Accept or decline
• Approve or reject
• Use this address or edit it
• Contact support or continue browsing

A simplified request looks like this:

{
  "type": "template",
  "altText": "Please confirm your booking",
  "template": {
    "type": "confirm",
    "text": "Confirm your booking for tomorrow at 10:00?",
    "actions": [
      {
        "type": "postback",
        "label": "Confirm",
        "data": "action=confirm_booking"
      },
      {
        "type": "postback",
        "label": "Cancel",
        "data": "action=cancel_booking"
      }
    ]
  }
}

Enter fullscreen mode Exit fullscreen mode

The two-action limit is not an arbitrary inconvenience. It protects the interaction model.

A confirm card asks one focused question:

Do you want to proceed?

Enter fullscreen mode Exit fullscreen mode

If the card is trying to explain several unrelated paths, it is no longer a confirmation step.

Use a buttons template for three or four actions

A buttons template is a separate LINE template type.

Choose it when users need a few visible actions on one compact card, such as:

View order
Track delivery
Change address
Contact support

Enter fullscreen mode Exit fullscreen mode

Unlike a confirm template, the buttons template can support up to four action objects.

It is a good fit when:

• there are three or four important choices;
• all choices belong to the same context;
• the actions should remain visible on one card;
• the content benefits from a title, text, or image.

Do not use four buttons merely because the component permits them. If one action is clearly primary and the others are secondary, consider simplifying the card or moving secondary options to the next step.

Use quick replies for temporary menus

Quick replies are useful when users need several immediate choices without a large permanent card.

For example:

Where should we route your request?

Billing
Delivery
Returns
Technical support
Sales
Other

Enter fullscreen mode Exit fullscreen mode

LINE supports up to 13 quick reply buttons.

That makes quick replies appropriate for:

• short category lists;
• selecting the next workflow step;
• choosing a language;
• selecting a date or location;
• answering a question immediately.

However, quick replies are temporary interface elements. They can disappear as the conversation moves forward.

Do not use them for actions users must be able to return to later.

If an option needs to remain available, consider:

• a buttons template;
• a rich menu;
• a carousel;
• a Flex Message;
• sending the menu again when needed.

Use a carousel for repeated objects

A carousel is better when users are selecting between repeated items with the same structure.

Examples include:

• products;
• subscription plans;
• store locations;
• appointment slots;
• support topics;
• delivery options.

Instead of presenting a flat list of unrelated buttons, each carousel column can represent one item:

Product A
Image
Price
View
Buy

Enter fullscreen mode Exit fullscreen mode

Product B
Image
Price
View
Buy

Enter fullscreen mode Exit fullscreen mode

Product C
Image
Price
View
Buy

Enter fullscreen mode Exit fullscreen mode

A carousel works well when users need to compare multiple objects.

It is a poor fit when the choices are simple workflow actions such as “confirm” and “cancel.” In that case, the additional visual structure only adds friction.

Use Flex Messages for custom hierarchy

A Flex Message is the most adaptable option.

Use it when the interaction depends on:

• custom branding;
• more complex visual hierarchy;
• multiple content sections;
• responsive layout;
• structured summaries;
• information-dense cards.

For example, an order confirmation might need to display:

Order number
Items
Delivery address
Payment status
Total
Primary action
Secondary action

Enter fullscreen mode Exit fullscreen mode

A Flex Message can express that hierarchy more clearly than a template with a fixed structure.

The trade-off is complexity.

Flex Messages require:

• more JSON;
• more layout decisions;
• more rendering tests;
• checking different screen sizes;
• validating fallback and accessibility text.

Do not choose Flex merely because it is flexible. Use it when the product experience actually needs a custom layout.

A practical decision function

You can model the initial choice in application code:

function chooseLineSurface({
  actionCount,
  isBinaryDecision,
  isTemporary,
  representsRepeatedItems,
  needsCustomLayout,
}) {
  if (isBinaryDecision && actionCount === 2) {
    return "confirm";
  }

  if (representsRepeatedItems) {
    return "carousel";
  }

  if (needsCustomLayout) {
    return "flex";
  }

  if (actionCount <= 4 && !isTemporary) {
    return "buttons";
  }

  if (actionCount <= 13 && isTemporary) {
    return "quickReplies";
  }

  return "redesignRequired";
}

Enter fullscreen mode Exit fullscreen mode

This is not a replacement for product judgment, but it makes the component boundaries explicit.

If the function returns redesignRequired, splitting the interaction into multiple steps is usually better than placing every possible action in one message.

A complete decision tree

Ask these questions in order.

1. Is this one binary decision?

Examples:

Yes / No
Accept / Decline
Confirm / Cancel

Enter fullscreen mode Exit fullscreen mode

Use a confirm template.

2. Are there three or four primary actions?

Use a buttons template.

Check whether all actions actually belong to the same card. If not, simplify the flow.

3. Are there several temporary next steps?

Use quick replies.

Design the workflow assuming those buttons may no longer be visible after the conversation continues.

4. Is the user comparing repeated objects?

Use a carousel.

Keep the column structure consistent so users can compare options easily.

5. Does the experience need a custom visual hierarchy?

Use a Flex Message.

Test the final JSON on different devices rather than assuming one preview represents every client.

6. Is the real problem receiving and routing the reply?

That is a separate architectural concern.

Use the official LINE Messaging API to render LINE-native UI. Then process the user’s reply through your inbound message pipeline.

Separate outbound presentation from inbound handling

The component used to send a message and the system used to process the response do not need to be the same layer.

A clean architecture separates them:

Official LINE Messaging API
        ↓
Render confirm, buttons, carousel, or Flex UI
        ↓
User taps or sends a reply
        ↓
Inbound webhook
        ↓
Queue, CRM, support system, or automation

Enter fullscreen mode Exit fullscreen mode

This matters for multi-channel systems.

Your application may use LINE-native components for outbound presentation while routing incoming LINE replies through the same backend that handles WhatsApp, Telegram, Zalo, TikTok, and X.

UnifyPort fits this inbound side. It does not render native LINE confirm templates, buttons templates, carousel templates, or Flex Messages.

An inbound LINE event can use a normalized envelope such as:

{
  "id": "evt_01j7lineconfirm8p7m4w6n2a",
  "type": "message.received",
  "provider": "line",
  "account_id": "acct_line_support_01",
  "occurred_at": "2026-08-25T09:30:00Z",
  "data": {
    "message": {
      "id": "msg_line_4281",
      "direction": "inbound",
      "type": "text",
      "text": "Confirm"
    },
    "conversation": {
      "id": "conv_line_2841"
    },
    "sender": {
      "id": "user_line_73"
    }
  }
}

Enter fullscreen mode Exit fullscreen mode

The backend can then route the event according to provider and reply content:

async function handleMessageReceived(event) {
  if (event.type !== "message.received") {
    return;
  }

  const message = {
    provider: event.provider,
    accountId: event.account_id,
    conversationId: event.data.conversation.id,
    senderId: event.data.sender.id,
    text: event.data.message.text,
  };

  await routeInboundMessage(message);
}

Enter fullscreen mode Exit fullscreen mode

The same handler can accept events from multiple providers without pretending that every provider offers identical outbound UI components.

Common design mistakes

Forcing a third action into a confirm flow

If a binary decision suddenly needs a third option, review the product requirement.

The third option may indicate that the interaction is actually a menu, not a confirmation.

Using quick replies for permanent navigation

Quick replies are temporary. Important navigation should use a surface designed to remain accessible.

Using Flex for every message

Flex provides control, but it also increases implementation and testing cost. Fixed templates are often better for simple interactions.

Treating all channels as visually identical

A normalized inbound event does not mean LINE, WhatsApp, Telegram, and other providers support the same outbound UI.

Keep provider capabilities explicit.

Combining outbound UI and inbound routing decisions

Choosing a LINE confirm template does not determine how your backend should store, assign, or route the response.

Design those layers separately.

Implementation checklist

Before selecting a LINE message surface, confirm that:

• [ ] A confirm template contains one binary decision.
• [ ] The confirm template has exactly two actions.
• [ ] Three or four visible actions use a buttons template.
• [ ] Temporary menus use quick replies.
• [ ] Repeated items use a carousel.
• [ ] Custom visual hierarchy uses a Flex Message.
• [ ] Flex layouts are tested across devices.
• [ ] Important actions do not depend on temporary quick replies.
• [ ] Official LINE APIs handle LINE-native presentation.
• [ ] Inbound replies are processed by a separate webhook pipeline.
• [ ] Other providers are not assumed to support the same UI.

Takeaway

Do not choose a LINE message component by asking:

How can I fit all these actions into one template?

Ask:

What kind of decision is the user making?

Use:

Confirm template → one binary decision
Buttons template → a few primary actions
Quick replies    → temporary next steps
Carousel         → repeated items
Flex Message     → custom visual hierarchy

Enter fullscreen mode Exit fullscreen mode

The best component is the one that makes the next decision obvious—not the one that can technically contain the most buttons.

References

• LINE message types
• LINE Messaging API reference
• Using quick replies
• Flex Message elements
• UnifyPort webhook event reference
• UnifyPort provider message support

This article was adapted from an original UnifyPort technical guide with AI-assisted editing.