Auto Response

Overview

Auto Response is the "keyword → Rich Message" rule engine for a LINE OA. When a user sends a chat message that matches a configured keyword, the system automatically replies with the Rich Message bound to that keyword — no admin involvement required.

The feature is aimed at teams who manage a LINE OA inbox and want to cut down on repetitive questions such as opening hours, branch locations, how to order, or the promotion of the month.

Each rule holds the following data:

Field	Description
Rule name	The label shown in the list, up to 100 characters
Keywords	Multiple keywords per rule; the rule fires when a message matches any one of them
Rich Message	The Rich Message sent back when the rule is triggered
Status	Active / inactive, switchable directly from the table

Key points to be aware of:

• Keywords are unique system-wide. The form checks for duplicates as you type; if a keyword is already taken, a notification appears with a link to the rule that owns it.
• Keywords belonging to active rules are surfaced as suggestions in other features that send text back into the chat — Quick Reply, Template Message, the Flex Card Builder, and Rich Message action areas.
• If the LINE OA message-handling priority is set to ai_classifier_only, a warning banner appears above the list, because in that mode the chatbot/AI classifier consumes every message and Auto Response never runs.

Business Flow

Managing the rule list

1. Opening the Auto Response list checks the user's access rights first (the VIEW permission on the auto-response module).
2. The system reads the current LINE OA configuration to determine whether message handling is set to ai_classifier_only; if so, a dismissible warning banner is shown above the table.
3. The table shows the row number, rule name (sortable), the linked Rich Message, status, and action buttons. If the linked Rich Message has been deleted or deactivated, a badge is shown in that column.
4. Rules can be searched by name and filtered by status. The most recent filter is remembered for the session, so returning to the page preserves the previous view.
5. Rules can be enabled or disabled straight from the switch in the table; the change is saved immediately without an extra confirmation step.
6. Deletion requires confirmation in a dialog. On success the system reports the result and refreshes the table automatically.

Creating and editing a rule

1. The form runs in four modes — create, edit, duplicate, and view-only — with the page title and action button adapting to the mode.
2. The list of active Rich Messages is loaded first, then the existing rule data, so the system can verify that the linked Rich Message still exists.
3. If the previously linked Rich Message has been deleted or deactivated, the field is cleared and an inline error prompts the user to pick a new one.
4. The user enters a rule name, one or more keywords, and selects a Rich Message. The keyword field accepts tag-style input, splits on commas, and truncates tag display at 30 characters.
5. Every time a keyword is added, the system checks it against every other rule. A duplicate is removed from the field immediately, along with a notification containing a button that opens the conflicting rule in a new tab.
6. The right-hand column renders a live chat preview so the result can be reviewed before saving.
7. The save button becomes available once the name, keywords, and Rich Message are all filled in and no validation errors remain.
8. Create mode saves directly; edit mode asks for confirmation first. On success the user is returned to the list page.

Reusing keywords in other features

1. Features whose text is sent back into the chat use a shared AutoComplete field that loads keywords from active Auto Response rules as suggestions (up to 100 rules).
2. Keywords from all rules are merged, de-duplicated, stripped of blanks, and shown with a badge identifying them as Auto Response keywords.
3. Free text remains fully supported — the suggestions only help ensure the configured text matches a rule that actually exists.

Key Screens & Components

List page (/auto-response)

• AI Classifier warning banner — shown when the LINE OA routes all messages to the AI classifier; it can be dismissed and does not affect anything else.
• Filter bar — a rule-name search box and a status selector, with search and clear actions.
• Rule table — row number, name, Rich Message, status switch, and edit/delete buttons, with name sorting and pagination.
• Confirmation and result dialogs — the standard modal set used across the CMS for delete confirmation, success, and failure.

Primary files: src/app/auto-response/page.tsx, src/components/auto-response/list/auto-response.container.tsx

Form page (/auto-response/form)

• Rule name field — required, capped at 100 characters, with a popover explaining the allowed characters.
• Keyword field — a tag input with no dropdown; keywords are typed manually and can be separated with commas.
• Rich Message selector — searchable over the loaded options, with a reload button for cases where a new Rich Message was just published.
• Status switch — controls whether the rule starts working immediately after saving (new rules default to active).
• Chat preview panel — a simulated LINE screen showing the selected Rich Message.

Primary files: src/app/auto-response/form/page.tsx, src/components/auto-response/form/auto-response-form.container.tsx, src/components/auto-response/form/auto-response-form.tsx

Shared component

src/components/common/auto-response-keyword-autocomplete.tsx — the AutoComplete field that offers active Auto Response keywords as suggestions. It is intended only for fields whose value is sent back into the chat, not for display-only text.

API service

All calls live in src/services/auto-response.service.ts under the auto-response base path.

Capability	Endpoint
List rules	GET /auto-response
Get a single rule	GET /auto-response/{id}
Create a rule	POST /auto-response
Update a rule	PUT /auto-response/{id}
Toggle status	PUT /auto-response/{id}/status
Delete a rule	DELETE /auto-response/{id}
Check keyword uniqueness	POST /auto-response/check-keyword-exists

Dependencies

• Permissions — both the list and the form are gated by the auto-response module permission; granting it unlocks the Auto Response and Quick Reply menus together.
• Rich Message Management — the source of the Rich Message options. If a linked Rich Message is deleted or deactivated, the rule stops working correctly and the form forces the user to pick a replacement.
• LINE OA Management — the messageHandlingConfig.priority setting determines whether the AI classifier intercepts messages before Auto Response can act on them.
• Quick Reply / Template Message / Flex Card Builder / Rich Message — consumers of the keyword suggestions, ensuring that buttons which push text back into the chat line up with real Auto Response rules.
• Shared infrastructure — the CMS authentication and HTTP client (automatic sign-out on token expiry), the breadcrumb and side-menu system, the standard modal set, and sessionStorage-based filter persistence, all shared with other list pages in the CMS.

Backend Details (CMS API)

cms-api is only the configuration side of Auto Response — it never sends the reply itself. The actual replying is done by a separate service, line-management-webhook-go, which reads what this page saves through a Redis cache.

The backend code lives in the internal/modules/autoresponse/ module.

Required permissions

• Every route is wrapped in the module gate for the auto-response module. If the organisation has not enabled that module, the request is rejected before it ever reaches the handler.
• Each endpoint is additionally checked against its own policy: readAll for listing and for the keyword-uniqueness check, read for fetching a single rule, and create / update / delete for the corresponding actions.
• Permanent deletion (hard delete) requires Super Admin — the module's delete permission alone is not sufficient.

Validation and business rules enforced by the backend

• Keywords must be unique within the same LINE OA. This is the module's central rule, which is why the backend exposes a dedicated POST /api/auto-response/check-keyword-exists endpoint (taking a payload with a keyword field) so the form can ask up front instead of waiting for a save to fail.
• The create endpoint (POST /api/auto-response) accepts multipart/form-data rather than pure JSON, so a file can be attached alongside the form fields in a single request.
• Toggling active/inactive is its own endpoint (PUT /api/auto-response/:id/status) and is decoupled from content edits. A rule can therefore be paused without resubmitting the whole rule payload and without deleting it.
• Listing (GET /api/auto-response) returns a paginated structure containing both the rows and the total count, and it joins the linked rich message server-side — which is why the list page can show the Rich Message name in one request.

What gets stored, and the side effects

• Rule data is stored in the auto_response table and references the rich_message and line_oa tables.
• After a create or an update the backend writes the Redis cache immediately, under the AUTO_RESPONSE:* key group (with a TTL), so the webhook does not have to query the database for every inbound message.
• At the same time the backend writes the LINE OA mapping into a Redis hash (the LINE_OA_ID key) so the webhook can quickly resolve which OA an inbound message belongs to.
• DELETE /api/auto-response/:id performs a soft delete — the row remains in the database. A real delete requires DELETE /api/auto-response/:id/hard plus an explicit confirmation query parameter (confirm=true), giving two layers of protection against accidental removal.

Edge cases worth knowing

• Because the webhook reads from the cache rather than the database, a failed cache write (or a cache that expires around a failed update) can mean an edited rule does not take effect immediately in the chat. If the bot keeps replying with the old content after a successful save, suspect the cache before suspecting the data.
• This module queries the rich message table directly from within itself rather than going through the rich message module's repository, so changes to the rich message data structure propagate into this module as well.
• Whether Auto Response receives a message at all still depends on the LINE OA message-handling priority. A successful save does not guarantee the rule will ever run if the OA routes all messages to the AI classifier.