ビジネスプロセスは、あらゆる形や規模のものがあります。自動化ワークフローは、最大限の生産性を発揮するために、これらのプロセスに合わせて柔軟に対応する必要があります。フローを作成する際に、必要なデータがすべて見つからないことがあります。そこで役立つのが「取得(fetch)処理」です。取得処理は、レコードの詳細を探してフローに取り込みます。これにより、フロー内でそのデータを文脈に応じて利用し、他のタスクを実行できるようになります。
取得処理はアプリごとに用意されており、そのアプリの他の処理と並んで表示されます。アプリがサポートしている内容に応じて、取得処理ではレコード名、メールアドレス、項目 ID(例:見込み客の Lead ID)などの値を基準に、追加の詳細を取得できます。この記事では、取得処理を使ってフローをどのようにカスタマイズできるかを説明します。
取得処理が役立つ代表的なケースをいくつか紹介します。
トリガーやアクションによっては、フローの次のステップで使いたいデータが提供されないことがあります。取得処理を使うと、そのデータを取得し、ビジネスプロセス全体を反映したワークフローを構築できるようになります。
たとえば、Shopify アカウントで新しい注文が作成されたときに、CRM に顧客情報を追加または更新するフローを作成したいとします。しかし、Shopify の新規注文トリガーには顧客情報が含まれていません。この場合、Shopify の顧客を取得アクションを使って顧客情報を取得し、そのデータを他の処理で利用できます。
同様のケースとして、TSheets で工数表が作成されたときに、関連ユーザーにメールを送信したい場合があります。しかし、新規工数表エントリートリガーで取得できるのはユーザー ID のみです。名前やメールアドレスなどの他の詳細を取得するには、ID を指定してユーザーを取得します。その後、取得した詳細をフロー内の他の処理で利用できます。

メモ:検索条件に一致するレコードが複数ある場合、Zoho Flow は最初に見つかったレコードのみを取得します。
プロセス要件に応じて、データ同士を関連付ける必要がある場合があります。たとえば、請求書と連絡先、タスクとチェックリスト、見込み客と担当者などを関連付けることができます。取得処理を使うと、フローを通じて関連付けに必要なデータを取得できます。
例を見てみましょう。フォームからの送信内容に基づいて Zoho Desk にチケットを作成するフローを作成するとします。Zoho Desk では、チケットは必ず連絡先と関連付けて作成する必要があります。そのため、Flow でチケットを作成する際は、連絡先 IDが必須項目です。これは Zoho Desk 上の連絡先の ID ですが、トリガーの差出人情報には含まれていません。チケットを作成する前に、メールアドレスまたは名前で連絡先を取得し、その ID を連絡先 ID項目にマッピングします。

メモ:各アプリは、レコードごとに固有の ID を持っています。たとえば、Zoho Desk の特定の連絡先 ID は、他のアプリで同じ連絡先を表す ID とは異なります。複数のアプリにまたがって同じレコードを扱う場合は、必ずそのアプリごとにレコードの詳細を取得してください。
次に、取得アクションを使って請求書と商品を関連付けるフローを見てみましょう。たとえば、Shopify アカウントで新しい注文を受け取るたびに、会計アプリ(Zoho Books、QuickBooks など)で請求書を作成したいとします。この場合、注文ごとに商品が変わるため、ドロップダウンから特定の商品を固定で選択することはできません。
しかし、この項目に値をマッピングする際には、会計アプリ(この例では Zoho Books)内での商品 ID が必要です。この ID を取得するには、営業請求書を作成アクションの前に取得アクションを追加して利用します。この ID を使って、特定の商品に対する請求書を作成するようにフローを設定できます。

メモ: 多くのアプリでは、ドロップダウンのカスタム値を使用オプションで、レコード ID(例:連絡先の場合は連絡先 ID)の指定が必要です。一部のアプリでは、名前やメールアドレスを指定できる場合もあります。
取得処理は、アプリ内にレコードが既に存在するかどうかを確認するのにも役立ちます。その結果に基づいて、フローに自動的な分岐処理を設定できます。このセクションでは、取得処理を使ってレコードを作成・更新する方法を説明します。
たとえば、製品の無料デモに興味のある人が登録できる Web フォームがあるとします。誰かがサインアップしたとき、その情報がまだ存在しない場合にのみ、CRM にリードを作成したいとします。
つまり、リードを作成する前に、そのリードが CRM に既に存在するかどうかをフローで確認する必要があります。そのために、タブエントリーを取得アクションを新規フォーム送信トリガーの後に追加します。
次に、リードが存在するかどうかを判定するための分岐(ディシジョン)を追加します。分岐条件として、Entry ID is null(エントリー ID が null)の条件を設定します。ここでのエントリー ID はレコード ID を指します。

レコード ID は、レコードを一意に識別する ID です。レコードが存在する場合は、そのレコード ID も存在します。この条件が満たされるということは、ID が存在しない、つまりリードが存在しないことを意味します。このフロー分岐内に、タブエントリーを作成アクションを追加し、リードを作成するように設定します。

一部の取得処理には、レコードが存在しない場合に新規レコードを作成するオプションが用意されています。このような処理を使用する場合は、分岐を追加する必要はありません。
例:Zoho Books の「連絡先を取得」アクション
複数のフォームがあり、特定の見込み客からのすべてのフォーム送信を追跡したいとします。この場合、フローはリードが既に存在するかどうかを確認し、詳細を更新するか、新しいリードを作成するかを判断する必要があります。
ここでも、取得アクションと、Entry ID is null条件を持つ分岐を使用します。この条件が満たされる場合は、レコードを作成するアクションを追加します。条件が満たされない場合は、レコードが既に存在することを意味します。既定の分岐にタブエントリーを更新アクションを追加します。

レコードを更新(または削除)する場合、通常はレコード ID が必須項目です。これにより、どのレコードを更新(または削除)するかを特定します。この値は、取得アクションから取得した値をマッピングして指定できます。
多くのビジネス活動において、アプリ間でデータを同期させておくことは非常に重要です。取得処理を使うと、この同期のためのワークフローを構築できます。たとえば、営業チームは Zoho CRM を、経理チームは Zoho Books を利用している場合、ビジネスプロセスを円滑に進めるには、両方のアプリケーションで連絡先情報を同期させておく必要があります。
もし互いに逆方向の処理を行う 2 つのフローを作成すると、無限ループが発生してしまいます。
フロー 1 が実行されると、CRM に連絡先が作成され、それがトリガーとなってフロー 2 が実行されます。フロー 2 は Books に連絡先を作成し、再びフロー 1 をトリガーします。このサイクルが繰り返され、重複した連絡先が次々と作成され、Flow のタスク数も消費されてしまいます。

これを防ぐには、各フローに取得アクションと分岐を追加し、連絡先が存在しない場合にのみ作成するようにフローを設定します。

この設定を行うと、フロー 1 が実行されて CRM に連絡先が作成され、フロー 2 がトリガーされます。フロー 2 の取得アクションではレコード ID が取得されるため、分岐条件は満たされず、フローは既定の分岐を選択します。その結果、Books 側で連絡先が再度作成されることはありません。
これにより、無限ループの発生を防ぎ、連絡先の重複作成や Flow タスクの無駄な消費を回避できます。
ご不明な点や検討したいユースケースがある場合は、support@zohoflow.com までメールでお問い合わせください。
「導入したばかりで基本操作や設定に不安がある」、「短期間で集中的に運用開始できる状態にしたい」、「運用を開始しているが再度学び直したい」 といった課題を抱えられているユーザーさまに向けた少人数制のオンライントレーニングです。
日々の営業活動を効率的に管理し、導入効果を高めるための方法を学びましょう。