このエントリーはエンジニアのキャリアを応援するLAPRAS と エンジニア採用のLAPRAS を提供する、LAPRASのアドベントカレンダー2024の8日目のエントリーです！
HubSpotのワークフローはローコードでいろんな自動化ができて便利な半面、エラーハンドリングが甘いところもあり、ワークフローでエラーが発生した場合もそのまま次のステップを実行する仕様であったり、その結果メール送信エラーやデータ不整合がそのまま気づかれすに放置されることもままあります。
このようなトラブルを防ぐために、
- エラーは起こる前提でフェールセーフな作りにしておくこと
- エラーや不整合な状況にいち早くチームが気付けること
という考え方を念頭に置き、自分なりに実践しているワークフローを「エラーに強く」作るためのアイデアをまとめました。
1. メールの送信エラーをハンドリングする
状況
ワークフローでのメールの送信は、コンタクトがオプトアウトしているなどの理由でよく失敗します。
マーケティングメールはオプトアウトの状態に従うべきですが、契約に関するメールなど必ず送信すべきメールの場合は早期に送信エラーを検知して対応したいですね。
ソリューション
メール送信ステップの次に「送信結果の条件分岐」を入れて、メール送信エラーをハンドリングしましょう。送信エラーの場合にはSlack通知などで担当者にエスカレすることで、クライアントや見込み顧客への影響を最小限に抑えられます。
分岐条件のプロパティに「アクション出力」を指定します
条件として送信結果を選択できます
できあがったワークフローと条件分岐
2. アサーションを入れてワークフローを中断する
状況
HubSpotは、ワークフローのステップでエラーがあってもそのまま処理を進める仕様です。値が設定できない、メールが送れない、関連オブジェクトが見つからない..という場合でも容赦なく次のステップの処理を行います。怖い。
例えば、コンタクトに「申し込みURL」をメール送信するワークフローで、「申し込みURL」のプロパティが未設定のままメール送信してしまうといったトラブル考えられます。
ソリューション
アサーションとしての条件分岐を追加します。
上記の例ではメール送信ステップの前に「申し込みURL」が設定されているかを確認する条件分岐を入れて、未設定の場合はメールを送信せずに異常検知をSlack通知して担当者がハンドリングできるようにしましょう。
(またここでワークフローを中断するか以降のステップを継続するかは要件によります)
アサーションの例
※すべてにアサーションを入れるのは現実的ではないので、クリティカルなステップの前や、よくエラーになるステップで活用しています。
3. 想定外の選択肢をエラーとしてハンドリングする
状況
フォームの選択肢に応じて分岐処理をしているワークフローがあるとします。
例えば選択肢が「はい」「いいえ」だった場合に、以下のワークフローような分岐条件だと、選択肢に「わからない」が増えたときに分岐を増やすメンテナンスを忘れてしまうとトラブルになります。(「いいえ」と「わからない」が正常に同じ分岐で扱われる)
ソリューション
将来的に選択肢が増えることを想定して、想定しない値が渡されたときにはエラーとしてハンドリングする作りにしておきます。
つまり擬似コードで書くならば、
if (選択肢=はい) はいの処理;
else いいえの処理;
ではなく
if (選択肢=はい) はいの処理;
else if (選択肢=いいえ) いいえの処理;
else エラー通知;
というように、想定する値と想定外の値のハンドリングを分けましょう。
こうしておけば選択肢が増えた場合にはエラーとして通知が来てメンテナンスの必要があることに気づけます。
想定外の値をハンドリング分ける場合
4. ワークフローのエラーをSlackに通知する
状況
エラーの発生をSlackに共有して気づいた人がすぐに対応したいですよね。
HubSpot仕様ではワークフローでエラーが起こった場合の通知機能はありますが、メンバーもしくはグループへのメール通知しかありません。
ソリューション
Slackでは「チャンネル投稿用のメールアドレス」を発行できます。
このチャンネル投稿用メールアドレスを持つユーザーを作成することで、そのユーザーへのメール通知＝Slackチャンネルへの投稿になります。
ワークフローの設定でエラー発生時の通知先として作成したユーザー指定すれば、エラー発生時にSlack通知が実現できます。
ワークフローの設定でユーザーを指定
※特殊なユーザーアカウントが増えるので、管理やセキュリティ上の懸念は要検討
5. ユニットテストのようなワークフローで整合性を保つ
状況
データの不整合は必ず発生します。とくにHubspotのような人手で入力するユースケースが多いシステムではなおのことです。
そして多くの場合、不整合が起こったプロパティを利用するときにはじめて不整合が起こっていると気づきます。(もしくは気づけません)
ソリューション
重要なデータの整合性をチェックする専用のワークフローを作っておくと安心です。
不整合に気づけるタイミングが早ければ早いほどトラブルに繋がるリスクを下げられます。
データ不整合が起こった場合のインパクトが大きいプロパティや、よく不整合が起こるプロパティについては、このようなワークフローを作成することで保険を掛けておくといいでしょう。
例えば、取引オブジェクトに「取引開始日」「取引終了日」があり、この日付が逆順(=不整合)になったことを検知します。
不整合を検知するワークフローの例
このようにHubspotのワークフローでもエラーや変化に対して強い設計をしたり、意図しない状況をいち早く検知する仕組みを整えることがある程度は可能なことがわかりました。
とはいえ検証の条件分岐を入れるとワークフローが複雑化・肥大化していくので、使い所はなかなか悩ましいのですが。クリティカルな部分については上記のようなアイデアを活用しています。
この記事がHubspotのワークフローの保守に向き合う誰かのご参考になれば幸いです。
Discussion