BubbleのWorkflowは「いつ起きるか」を表すイベントと、「何をするか」を表すアクションを組み合わせて作ります。フォーム保存や画面遷移など身近な操作から考えると、仕組みを理解しやすくなります。
01イベントを一つ決める
たとえば「保存ボタンがクリックされたら」というイベントを置きます。入力値が変わった場合やページが読み込まれた場合など、別のきっかけもありますが、最初は目的が明確なイベント一つで作る方が追跡しやすくなります。
02アクションを小さく並べる
問い合わせフォームなら、入力内容を検証し、データを保存し、完了表示へ進む流れです。処理を詰め込みすぎず、各段階で何ができたか確認します。条件付きアクションを使う場合は、条件に合わず実行されなかった後続処理がどうなるかも試してください。
03失敗時の動作を設計する
入力不足、権限なし、外部APIの失敗などを想定します。「保存されたと思ったのに保存されていない」を防ぐため、成功時と失敗時で異なる表示にします。二重クリックによる重複登録も、実際の操作で確認したい点です。
04名前とテストを残す
Workflowには役割が分かる名前を付けます。公開前には通常ケースだけでなく、空欄、長い入力、通信失敗、異なる権限の利用者を試します。原因を見つけやすい小さなWorkflowの積み重ねが、後からの修正を楽にします。
05具体例：問い合わせを保存するWorkflow
架空の問い合わせフォームで「送信ボタンが押された」をイベントとします。実行前にメールアドレスと本文が空でないか確認し、入力に問題がなければ「問い合わせ」を1件作成し、その結果を確認して完了表示へ進めます。入力不足なら保存せず、該当欄に修正を促します。外部メール通知も行う場合は、保存と通知のどちらが失敗したときに何を表示・再試行するかを分けて決めます。
特に「保存は成功、通知は失敗」のときに送信者へ単純な失敗表示を出すと、再送で同じ問い合わせが増えることがあります。二度目の操作をどう扱うか、担当者が通知失敗にどう気づくかを試験します。保存済みの1件を重複作成しない条件はアプリの識別子や業務フローに合わせて設計し、ボタンを一時的に押せなくするだけを唯一の対策にしません。
確認表には「正常」「本文が空」「許可のない利用者」「外部通知が失敗」「送信ボタンを連打」を並べ、データ件数、画面表示、通知件数をそれぞれ記録します。見た目で成功したように見えるかではなく、保存結果と次に取れる行動で合否を決めます。
参考資料
内容は公開時点の公式資料をもとに構成しています。仕様は変更されることがあるため、導入時は最新の公式情報をご確認ください。