# 実現したいこと（ゴール）
コールオブジェクトが作成されたら、作成されたコールオブジェクトの情報を取得したい
# 意図・背景
コールオブジェクトの通話メモやレコーディング情報から、コールの要約を作成したいと思っています。コールオブジェクトの作成をトリガーに、外部のAPIを使用して要約することを考えていますが、コールオブジェクトの作成をトリガーに、外部APIを起動する方法が分かりません。
# 試したこと
HubSpotのWebhookを使用して次のように解決しようと考えました。
## コールオブジェクトの作成をトリガーにする
不可能でした。コールオブジェクトの作成をトリガーに選択することができませんでした。
## プロパティ値の変更をトリガーにする
プロパティ「前回の連絡」の値の変更をトリガーにすることで、コールオブジェクトの作成をトリガーにすることができましたが、コールオブジェクトの作成以外のイベントでもWebhookが起動してしまいます。
# 相談したいこと
- コールオブジェクトの作成をトリガーにWebhookを起動する方法はありますでしょうか？
- コールオブジェクト以外のオブジェクトの作成をフィルタリングする方法はありますでしょうか？
- ゴールを達成するために考えらえる別のアプローチはありますでしょうか？
# 備考
- Marketing Hub Enterprise を利用
- CMS Hub Enterprise を利用
以上となります。
よろしくお願いいたします。
@野中高亮 さん、コミュニティーへの投稿ありがとうございます。
ご状況は以下のいずれかでしょうか？
・「コール」というカスタムオブジェクトがあり、新しくコールのレコードが作成されたら要約を作りたい
・コンタクトレコードや会社レコードに、新しくコールのログが作成されたら要約を作りたい
開発者向けWebhookの資料（HubSpot APIドキュメント - Webhook）を確認しましたが、サブスクリプションにコール関連のものが見当たらないのでご希望のことは難しいのかなと…。
詳しそうな方をメンションさせてください： @assi @KMurota @Makoto
他のアプローチで良い方法がありそうでしょうか？
Makoto
3
@野中高亮 さん、初めまして篠原と申します。
HubSpotのコール情報を外部システムに送り込みたい感じですね。
Webhookを使ってリアルタイムでコール情報を連携するコストがかかる方法に本当にすべきかは微妙ですが、
外部システムから数分おきにバッチで監視して、一括で取得する方法のほうがコストがかからないような気がします。
その場合は、下記のコールエンゲージメントAPIを活用すればできそうです。
@skimura 先生、エンジニアとしてフォローお願いします。
@野中高亮 さん、初めまして
よろしくお願いいたします。
僭越ながら記載させていただきます。
ワークフローを確認しましたが
`コール`オブジェクトを直接にトリガー、フィルターに設定する方法は見つけられませんでした。
独自のバッチ処理、APIを利用する前提であれば下記の方法が考えられそうです。
## 「前回の連絡」プロパティの変更をトリガーとすることで
「コールオブジェクトの作成」（以外も含め）イベントを捉えることができるのであれば
「オブジェクトの状態を確認しトリガーが、[コールオブジェクトの作成イベント]の場合は外部APIを呼び、そうでない場合は何もしない」APIを用意し、ワークフローからはこのAPIを呼ぶというのはいかがでしょうか。
※判定方法は、「前回の連絡」が変更されたオブジェクトに関連づけられた`コール`オブジェクトを見ることで「コールオブジェクトの作成」によりトリガーが働いたか判断する等を想定
（関連づけられた`コール`オブジェクトの作成日時を見る等：要検証）
## また @Makoto さんの提案された
「外部システムから数分おきにバッチで監視して、一括で取得する方法」の場合は
Hubspot API の検索において[エンゲージメント コール]は対象となっていますので
下記のようなバッチで実現できるのではないでしょうか。
```
下記の条件でコールオブジェクトの検索を実施してその結果を利用する
`コール`の作成日時が [前回の実行時間 > `コールオブジェクトの作成日時` >= 現在日時]
```
参考になれば幸いです。
よろしくお願いします。
@Makoto
お知らせいただきありがとうございます。
> - コールオブジェクトの作成をトリガーにWebhookを起動する方法はありますでしょうか？
> - コールオブジェクト以外のオブジェクトの作成をフィルタリングする方法はありますでしょうか？
ドキュメントによると、「前回の連絡」プロパティはコール以外にEメール等の連絡でも更新されます。
そのため、 @skimura さんが書かれているように「何をトリガーにして前回の連絡が更新されたか」を判断するロジックを自前で用意する必要があります。
もし、追加のランニングコストが許容できるのであれば、Operations Hub を契約してカスタムコードアクションで上記のロジックをワークフロー内に実装すれば、外部のAPIやバッチ処理を用意しなくてもゴールは達成できそうです。
＠返信してくださった皆
新年早々に、丁寧かつ迅速な返信ありがとうございます。
皆様のアドバイスのおかげでやりたいことを実現できそうです。
@skimura, @yskz_aoyama
--- 引用 ---
「オブジェクトの状態を確認しトリガーが、[コールオブジェクトの作成イベント]の場合は外部APIを呼び、そうでない場合は何もしない」APIを用意し、ワークフローからはこのAPIを呼ぶというのはいかがでしょうか。
※判定方法は、「前回の連絡」が変更されたオブジェクトに関連づけられた`コール`オブジェクトを見ることで「コールオブジェクトの作成」によりトリガーが働いたか判断する等を想定
（関連づけられた`コール`オブジェクトの作成日時を見る等：要検証）
--- 引用 ---
ご指摘いただいた上記の方法が簡単かつコストを抑えることができそうな実装だと思いました。
今回はこちらのアプローチで実装をしてみて、改めて疑問点などが出てきましたらご相談させていただければと幸いです。
--- 引用 ---
追加のランニングコストが許容できるのであれば、Operations Hub を契約してカスタムコードアクションで上記のロジックをワークフロー内に実装すれば、外部のAPIやバッチ処理を用意しなくてもゴールは達成できそうです。
--- 引用 ---
現時点では、Operations Hub を契約することによる追加のコストと、Webhook通知の送信側APIでの処理のコストを勘案して後者で実装するのが良さそうです。
ただし処理すべきリクエスト数が増えてきた場合や、今回とは別のサービス連携など必要になった場合は改めて検討させていただければと思います。
以上となります。
改めて迅速かつ的確なアドバイスをありがとうございます。
引き続きよろしくお願いいたします。
@野中高亮
ちなみにですが、Make.comにはWatch Engagementというモジュールがありまして、みなさんが述べられているようなロジックがビルトインされています(裏側ではList Engagementsを前回PullしたもののCreated dateを記憶しつつバッチ実行している)。
コストとしては無料~$10前後/月のプランから始められます。
/crm/v3/objects/callsをバッチ処理で叩くのであれば、関連付け関係ないのではないでしょうか？
