Workflow Automation

Overview

Workflow Automation is a drag-and-drop visual flow builder that lets OA administrators design automation on a canvas instead of configuring one rule at a time through a form. A workflow is a graph of nodes connected by edges: it starts at a trigger node, branches through conditions, delays, and splits, and ends at action nodes.

It suits teams that need multi-step automation where a single Trigger Rule is not enough — onboarding new members, drip content series, win-back journeys for inactive users, or follow-up messages after a campaign click.

Topic	Detail
Main pages	List (/workflow), canvas (/workflow/form), execution history (/workflow/logs)
Workflow status	draft / active / inactive
Node types	30 types across 7 groups: trigger, condition, action, flow control, AI, apps, utility
Ready-made templates	17 templates in 5 groups (Onboarding, Segmentation & Engagement, Campaign Attribution, Scheduled & Nurture, Appointment)
Structural constraints	The graph must be acyclic, every trigger needs an outgoing edge, and every non-trigger node needs an incoming edge

Key points to be aware of:

• Activating a workflow compiles it into backend Trigger Rules. The Trigger Rule list tags those rules with the owning workflowId / workflowName, and they should not be edited directly.
• Every save and every activation is recorded as a version that can be rolled back later.
• Before activation the system validates the entire flow and points to the specific nodes that need fixing.

Business Flow

1. Managing the workflow list

1. The list page loads workflows page by page, sorted by newest first, keeping the previous page rendered while the next one loads so the table does not flicker.
2. The table shows the workflow name (a link into the canvas), status, node count, last modified date, and row actions.
3. Each row offers five actions: view execution logs, edit on the canvas, clone, toggle active state, and delete.
4. Deletion requires confirmation in a dialog; cloning and status toggles apply immediately.
5. Every action refreshes the table and reports the result through a success or failure dialog.
6. Toggling status from the list does not run client-side validation — the backend decides — unlike the activate button on the canvas, which always validates first.

2. Designing a flow on the canvas

1. Opening the canvas preloads every option set the node configuration panel may need: merge tags, audiences, manual (CSV) audiences for add/remove actions, Rich Menus, Rich Messages, Friend Track campaigns, campaigns with tracking spots, and Knowledge Bases.
2. In edit mode the existing graph is loaded along with per-node execution statistics, which appear as badges on the nodes.
3. During loading, values stored as identifiers (audiences, Rich Messages, and similar) are enriched with their display names so nodes can render readable labels without extra API calls.
4. Nodes are dragged from the Node Palette on the left onto the canvas; each drop creates a node with a unique id, and some node types receive sensible defaults.
5. Edges are drawn between nodes to define the sequence, and validity is checked while the connection is still being dragged.
6. The canvas supports snap-to-grid, a minimap, percentage zoom controls, and two mouse modes — pan (drag the background to move) and select (rubber-band selection of multiple nodes).

3. Connection rules

1. Action nodes are normally terminal and cannot connect onwards, with two exceptions:
   • action_web_request may only connect to other action nodes.
   • action_advanced_send_message with tracking enabled may connect to a single delay_wait node.
2. The exit node is always terminal.
3. Branching nodes (condition, delay, split test, multi-split, GenAI intent classifier) attach branch information to each edge so the system knows which outcome the edge represents.
4. Each edge is labelled according to its branch — yes / no, completed / expired, split groups A–D, multi-split branch names, or GenAI intent names.

4. Configuring nodes

1. Clicking a node opens the Node Config Drawer on the right; clicking empty canvas closes it.
2. The drawer saves automatically — there is no separate save button, and every keystroke is written back into the graph.
3. Text fields support merge tags through an insert-tag button, grouped into user fields, custom attributes, and system attributes; the selected tag is appended in double-brace form ({{tag}}).
4. New attributes and new audiences can be created inline from the drawer without leaving the canvas.
5. action_web_request has two dedicated helpers:
   • Import from cURL — paste a cURL command and the system extracts the method, URL, headers, and body, and infers the content type (JSON, form-urlencoded, or raw).
   • Parse Response — paste a sample JSON response and the system walks it to list every leaf path (for example $.data.name) as selectable mappings. A downstream action_update_attribute node inherits those mappings automatically.
6. action_advanced_send_message traces the flow upstream to detect a booking trigger. When one is found, the booking merge tag set (booking.serviceName, booking.date, booking.status, and others) becomes available.
7. action_advanced_send_message and GenAI intents share the same response configuration with four modes: AI-generated text, Knowledge Base answers (with configurable topK and semantic ratio), an existing Rich Message, and a custom Flex Message. Quick Replies can be attached in every mode except Rich Message.
8. The Flex Builder converts LINE Flex JSON into an editable tree with live preview, plus an AI generation button that drafts a layout from a text description.

5. Complex node configurations

trigger_scheduled — five scheduling presets, with a choice of nine timezones (Asia/Bangkok is the default).

Preset	Required fields
interval	Interval value (1–1440) and unit (minutes or hours)
daily	Hour (0–23) and minute (0–59)
weekly	Day of week, hour, and minute
monthly	Day of month (1–31), hour, and minute
custom	A custom schedule expression

multi_split — supports two to six branches per node, each defined by a key, an operator, and a comparison value, plus an else fallback branch that is enabled by default. Removing a branch re-indexes the remaining branches and automatically deletes the edges attached to the removed handle. When the upstream node is trigger_campaign_click, a one-click action generates branches from the campaign's tracking spots (up to six).

delay_wait — defines a wait duration (minutes, hours, or days) and an expiry, with an option to re-evaluate conditions once the wait ends. If the upstream node is an action_advanced_send_message with tracking enabled, the node can additionally wait for a click: either any link click, or a click on a specific spot (spot options are extracted from the upstream Flex Message).

6. Templates and AI-generated flows

1. The Template button opens a gallery of 17 ready-made flows such as Welcome New Member, VIP Upgrade, Audience Re-engagement, Drip Content, Birthday Greeting, and Booking Confirmation.
2. Selecting a template replaces the entire canvas immediately with no confirmation, so any existing work should be saved first.
3. The AI button accepts a description of the desired automation (up to 2,000 characters) and generates the graph, also filling in the workflow name if it is still empty.
4. The camera button exports the canvas as a PNG named after the workflow.

7. Saving and activating

1. Saving requires only a workflow name — unless the workflow is already active, in which case full validation is enforced and the button changes to save and recompile.
2. Activating requires the flow to pass every validation rule:
   • At least one trigger, and every trigger must have an outgoing edge.
   • Every node must be configured (annotation and exit nodes are exempt).
   • Condition nodes must connect both the yes and no branches.
   • delay_wait must connect its completed branch, wait at least 60 seconds, and must not chain directly into another delay.
   • split_test needs at least two paths whose percentages add up to exactly 100.
   • multi_split needs at least two fully configured branches and an outgoing edge.
   • action_web_request requires a URL and method; a body that contains no merge tags must be valid JSON.
   • genai_intent_classifier needs at least one intent, each with a label and an outgoing edge, and the fallback intent must reference an existing intent.
   • trigger_message_received is limited to one per workflow and may only connect to a genai_intent_classifier.
   • The graph must contain no cycles.
   • The system also raises non-blocking warnings for paths that dead-end without reaching an action or exit node.
3. Once validation passes, a confirmation dialog appears with wording matching the chosen operation, and the graph is converted into a clean payload.
4. A successful first save navigates to the canvas of the newly created workflow rather than back to the list; editing an existing workflow reloads the data in place.

8. Version history and rollback

1. The history button appears only for saved workflows, and versions are loaded lazily when the drawer is opened.
2. Each version shows its version number, event type (save, activate, or rollback), timestamp, and the user who performed it.
3. Preview renders that version's graph read-only; Rollback (behind a confirmation step) restores it.

9. Testing and monitoring

1. Test Run — enter a LINE user id and run the flow, either as a dry run or for real. Real runs display a prominent warning because messages are actually delivered. Results are listed per node with success, failure, or skipped status and any error message.
2. Chat Sandbox — a chat panel beside the canvas for talking to the flow as if you were a real user. Its debug panel shows the matched intent and confidence, how it matched (keyword, AI, or fallback), the response mode, a processing-time breakdown by stage, and the Knowledge Base chunks that were retrieved. Quick Replies returned by the bot can be tapped to continue the conversation.
3. Node statistics — badges in the upper-right corner of each node showing total runs, failures, and pending executions.
4. Status indicator — the current status with the timestamp of the most recent execution.

10. Execution history page

1. Reached from the logs button on the list page; without a workflow reference the page shows an empty state.
2. Three summary cards sit at the top: total executions with success and failure counts, a success-rate gauge (green at 90% or above, amber at 70% or above, red below), and node coverage with the three most active nodes.
3. Logs can be filtered by keyword, status, node type, and date range, with a clear-filters button that appears whenever filters are applied.
4. The table lists the LINE user id (truncated in the middle and copyable), the node that ran, status, execution source (manual test or automatic), the error message, and the timestamp.

Key Screens & Components

List page (/workflow)

• Workflow table — name, status, node count, modified date, and the view-logs / edit / clone / toggle / delete actions.
• Confirmation and result dialogs — the standard CMS modal set.

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

Canvas page (/workflow/form)

• Node Palette (left) — the node library in seven collapsible groups, collapsible to a narrow icon rail; every card is draggable onto the canvas.
• Canvas (centre) — the flow drawing surface with minimap, dotted background, zoom controls, and the mouse-mode toggle.
• Top toolbar — workflow name, status indicator, and the Template / AI generate / export PNG / Test Run / Chat Sandbox / version history buttons alongside save and activate.
• Node Config Drawer (right) — the auto-saving configuration panel covering every node type, including the merge tag picker, inline attribute and audience creation, cURL import, and response parsing.
• Chat Sandbox (right) — the test chat panel with debug output, shown in place of the config drawer.
• Version History Drawer — a version timeline with preview and rollback.

Primary files: src/app/workflow/form/page.tsx, src/components/workflow/form/workflow-form.container.tsx, src/components/workflow/form/workflow-form.tsx, src/components/workflow/form/components/node-config-drawer.tsx

Execution history page (/workflow/logs)

• Three summary cards — execution volume, success rate, and node coverage.
• Filter bar — keyword, status, node type, and date range.
• Log table — individual executions with full error messages in tooltips.

Primary file: src/app/workflow/logs/page.tsx

Supported node groups

Group	Example nodes	Notes
Trigger	Attribute change, audience membership, schedule, Friend Track event, campaign click, message received, unified trigger	trigger_advanced covers six source types in a single node
Trigger (Apps)	Booking created, booking cancelled, booking status changed, booking reminder	Pulls journeys, locations, and services from the Appointment module
Condition	Attribute condition, audience condition, multi-split	The first two expose yes and no outputs
Action	Send message, switch Rich Menu, add/remove audience member, update attribute, external web request, advanced send message, talk to agent	Mostly terminal nodes
Action (Apps)	Send booking link, update booking status
Flow control	Delay/wait, split test	Split test supports up to four paths totalling 100%
AI	GenAI intent classifier	Unlimited intents, each matched by AI or by keyword
Utility	Canvas annotation, exit	Skipped during validation

API service

All calls live in src/services/workflow.service.ts under the workflows base path.

Capability	Endpoint
List workflows	GET /workflows
Get a single workflow	GET /workflows/{id}
Create / update / delete	POST /workflows, PUT /workflows/{id}, DELETE /workflows/{id}
Clone	POST /workflows/{id}/clone
Activate / deactivate	POST /workflows/{id}/activate, POST /workflows/{id}/deactivate
Execution logs	GET /workflows/{id}/logs
Per-node statistics	GET /workflows/{id}/stats
Versions, version detail, rollback	GET /workflows/{id}/versions, GET /workflows/{id}/versions/{versionId}, POST /workflows/{id}/versions/{versionId}/rollback
Test run	POST /workflows/{id}/test-run
Test chat	POST /workflows/{id}/test-chat
AI flow generation	POST /workflows/generate

The configuration drawer also calls a few endpoints directly when needed: Mbox teams (GET /line-oa/{lineOaId}/mbox/teams) and Appointment data (GET /apps/appointment/journeys, GET /apps/appointment/locations, GET /apps/appointment/locations/{id}/services).

Dependencies

• Trigger Rule — the compilation target for activated workflows. Rules generated from a workflow are tagged with their origin in the Trigger Rule list, and both features share the same condition and frequency vocabulary.
• Audience Management — the source for audience membership triggers and audience conditions. Add/remove member actions are deliberately restricted to manual (CSV) audiences so that filter-computed audiences are never modified.
• Rich Message / Rich Menu — the options behind the send-message and switch-menu actions, limited to active items.
• Attribute Master and System Attribute — the source of merge tags and the target of the update-attribute action, with inline attribute creation available from the drawer.
• Friend Track and Campaign — supply campaign and tracking-spot data for the campaign click trigger and automatic branch generation.
• Knowledge Base — powers the retrieval-based response mode used by GenAI intents and advanced messages.
• Apps Appointment — supplies journeys, locations, and services for the booking node group.
• Mbox — the destination of the talk-to-agent action, including team selection.
• Form Builder — one of the source types available to the unified trigger (form submitted).
• Shared infrastructure — the CMS authentication and HTTP client (automatic sign-out on token expiry), the breadcrumb and side-menu system, and the standard modal set; canvas state is kept in a dedicated workflow store.

Backend Details (CMS API)

Workflow is the largest module in cms-api. Its code lives in internal/modules/workflow/ and is split by responsibility.

Code area	Role
service	CRUD, version management, activate/deactivate, statistics
executor	The engine that walks the flow node by node
sandbox	The machinery behind Test Run and the Chat Sandbox, including RAG retrieval
ai / prompt	AI-drafted flows generated from a text description

Required permissions

• Every route is wrapped in the module gate for the workflow module; if the organisation has not enabled it, requests are rejected before reaching the handler.
• Policies are split by action: read for the list, detail, statistics, logs, and versions; create for creating, cloning, and AI generation; update for editing, activating/deactivating, rolling back, parsing responses, and Test Run; delete for removal.
• Note — the Chat Sandbox endpoint is gated on the line-oa module's read policy rather than the workflow one, inherited from the previous system. Someone with LINE OA read access can therefore try the test chat even if their workflow permissions are narrower.

Validation and business rules enforced by the backend

• The number of simultaneously active workflows is capped by the plan quota (maxActiveWorkflows). Activation can therefore be refused for exceeding the quota even when the flow is complete and passed every client-side check.
• The quota is checked at save and activation time, not while designing, so any number of drafts can exist — the limit applies only to workflows that are actually running.
• POST /api/workflows/parse-response is a backend endpoint that converts and validates the response spec for nodes calling external APIs, so field mapping from a sample JSON payload is not derived on the client alone.
• POST /api/workflows/generate sends the human-language description to the AI and returns a drafted flow structure. It is gated on the create policy because its output is a new flow.

What gets stored, and the side effects

• Data spans several tables: workflow (the flow itself), workflow_version (version history), trigger_rule (the compiled rules), and the knowledge tables knowledge_base / knowledge_document / knowledge_chunk for the Knowledge Base response mode.
• Activation writes across module boundaries, creating and adjusting rows in trigger_rule to match the flow. This is why rules tagged as workflow-owned must not be edited directly — the next workflow save overwrites them.
• External API calls are not made by cms-api directly. The work is published to the web_request_execute queue and line-management-worker-go performs the actual call. The message_received_trigger queue is the path by which inbound messages wake a flow.
• While the Chat Sandbox runs, the backend calls two external services: an embedding API to vectorise the text, and Meilisearch to retrieve the closest knowledge chunks. Both endpoints are configured through environment variables (EMBEDDING_API_URL, MEILISEARCH_HOST, MEILISEARCH_API_KEY).
• Deleting a workflow is a soft delete that stamps the deleted_date column.

The AI configuration behind the scenes

The AI flow-generation button and the Flex Builder both depend on AI settings stored separately in the ai_config table, per LINE OA / organisation, holding the provider, model name, API key, and generation parameters.

• GET /api/ai-config reads the current settings, and PUT /api/ai-config saves them as an upsert (there is no separate create versus update).
• POST /api/ai-config/generate-flex takes a text description (the prompt field) and returns Flex Message JSON for the rich message editor to drop in.
• Gemini is the only provider actually implemented. The code leaves room for others, but selecting a different provider will not work today.
• Omitted parameters fall back to defaults, and the backend explicitly distinguishes "not supplied at all" from "supplied as zero" — sending 0 therefore means a real zero, not "use the default".
• Security note — all three ai-config endpoints sit on the public route group requiring only a login-level token (no OA selection needed) and are not wrapped in a module gate, while the declared policy is still unenforced. Given that this table also stores the provider API key, this is worth revisiting when tightening permissions.

Edge cases worth knowing

• The workflow, workflow_version, and trigger_rule tables do not use the ORM's automatic soft-delete mechanism; every query must spell out the "not deleted" condition, and forgetting it mixes deleted records back into results.
• Because external API calls travel through a queue, their outcome is asynchronous. Test Run reporting a node as passed does not confirm that the remote endpoint actually responded successfully.
• The Chat Sandbox depends on external services. If the embedding endpoint or Meilisearch is unavailable, the Knowledge Base response mode cannot be tested even though the flow itself is perfectly valid.
• The default MEILISEARCH_HOST points at the local machine, so if it is not configured for the real environment, knowledge retrieval fails quietly. Check the environment variables before suspecting the Knowledge Base content.
• Activation is not merely a status change — it compiles the graph into rules, so a successful activation can take noticeably longer than an ordinary draft save.