ファイルを添付したら添付ありチェックを入れたいその２（スケジュールトリガ）
Winter'23で追加された演算子「次に含まれる」が活躍しました
キウイ
{{getTime(record.UpdatedTime)}}
記事「ファイルを添付したら添付ありチェックを入れたいその１（レコードトリガ）」の続きです。
タイムラグ：スケジュールフローのスケジュール頻度次第（当日○時）
ファイルアップロード後に添付先レコードの更新が発生しない場合は、自動化の起点を添付先レコードではなく、「コンテンツドキュメント」にする必要があります。しかし前回記事の冒頭で触れたとおりレコードトリガフローの開始条件ではコンテンツドキュメントオブジェクトを選択できないため、スケジュールトリガフローで深夜0時に前日アップロードされたファイルに対して処理を行います。
作成したフローはこちら
（4/13修正しました🙇♀️②*と⑩*を追加しています）
スケジュールトリガフローでは【＋オブジェクトを選択】で「コンテンツドキュメント」オブジェクトも選択可能ですが、「昨日作成された」という条件指定ができないので、開始条件ではオブジェクトは省略し、実行頻度と時間だけ設定します。
（要素の設定時に新規作成も可能です。）
条件の要件：すべての条件に一致(AND)
保存するレコード数：すべてのレコード
レコードデータの保存方法：すべての項目を自動的に保存
表示ラベル：あり
結果を実行する条件の要件：すべての条件に一致(AND)
コレクション変数：２で取得したコンテンツドキュメントレコードコレクション変数
条件の要件：すべての条件に一致(AND)
並び替え順：並び替えなしでも問題ないですが、整理のために「LinkedEntityId」順にしました。
保存するレコード数：すべてのレコード
レコードデータの保存方法：すべての項目を自動的に保存
結果を実行する条件の要件：すべての条件に一致(AND)
デフォルトの結果の表示ラベルもわかりやすく「応募者ではない」にします。
結果の表示ラベル：重複
結果を実行する条件の要件：すべての条件に一致(AND)
デフォルトの結果の表示ラベルもわかりやすく「重複ではない」にします。
７と８の決定要素は、無くてもエラー無くフローは実行されて想定通りの挙動にはなります。
最終的に処理するIdのコレクションをより綺麗なものにするためにオブジェクトと重複のチェックを入れています。
表示ラベル：あり
結果を実行する条件の要件：すべての条件に一致(AND)
更新するレコードを検索してその値を設定する方法：レコードを識別する条件を指定し、項目を個別に設定
オブジェクト：応募者（添付先オブジェクト）
レコードを更新する条件の要件：すべての条件に一致(AND)
項目値をレコードに設定：
今回の「応募者」の例だとここで『「選考状況」←「書類受付済み」』を追加しても良いですね
▼4/10にファイルタブやライブラリへアップロード→4/11に応募者レコードへ「追加」→4/12になっても添付ありチェック入らず
ContentDocumentLinkレコードを起点にできれば良いのですが、ContentDocumentLinkはレコード取得時の制限が厳しく、「ContentDocumentIdかLinkedEntityIdが単一のIdと一致する」か、あるいは「Idがコレクション変数に含まれる」の条件指定が必要で、作成日や添付先オブジェクトで取得レコードを絞れません。そのためContentsDocumentを起点にせざるを得ませんでした。
その１その２の全2編でお送りしましたが、ファイルまわりで引き続き検証中の内容もあるのでその内その3（画面フローで…）を執筆するかもしれません。
レコード画面からメール送信時の添付ファイルを、そのレコードにも関連づけてファイルを格納したい
ご要件：添付ファイルをアップロードしたら「添付あり」にチェックを入れたい
策２．スケジュールトリガフローで直近にアップロードされたファイルに対して対応する
難易度：中タイムラグ：スケジュールフローのスケジュール頻度次第（当日○時）
ファイルアップロード後に添付先レコードの更新が発生しない場合は、自動化の起点を添付先レコードではなく、「コンテンツドキュメント」にする必要があります。しかし前回記事の冒頭で触れたとおりレコードトリガフローの開始条件ではコンテンツドキュメントオブジェクトを選択できないため、スケジュールトリガフローで深夜0時に前日アップロードされたファイルに対して処理を行います。
作成したフローはこちら
（4/13修正しました🙇♀️②*と⑩*を追加しています）
１．スケジュールトリガフローで開始条件を設定
スケジュールトリガフローでは【＋オブジェクトを選択】で「コンテンツドキュメント」オブジェクトも選択可能ですが、「昨日作成された」という条件指定ができないので、開始条件ではオブジェクトは省略し、実行頻度と時間だけ設定します。
以降の設定で使用するリソースの準備
【新規リソース】ボタンから３つリソースを作成しておきます。（要素の設定時に新規作成も可能です。）| API名（例） | リソース種別 | データ型 | その他 |
| formula_Yesterday | 数式 | 日付 | 数式：TODAY()-1 |
| coll_ContentDocument | 変数 | テキスト | 複数の値を許可（コレクション）にチェック |
| coll_LinkedEntityIds | 変数 | テキスト | 複数の値を許可（コレクション）にチェック |
２．「レコードを取得」要素で前日にアップロードされたファイルを取得
オブジェクト：コンテンツドキュメント条件の要件：すべての条件に一致(AND)
| 項目 | 演算子 | 値 |
| CreatedDate | 以上 | formula_Yesterday |
保存するレコード数：すべてのレコード
レコードデータの保存方法：すべての項目を自動的に保存
２*．「決定」要素で取得できたレコードがあるかチェック
前日にアップロードされたファイルが存在しない場合にエラーとなってしまうため、nullかチェックします。表示ラベル：あり
結果を実行する条件の要件：すべての条件に一致(AND)
| リソース | 演算子 | 値 |
| ②で取得したコンテンツドキュメントコレクション | null | False |
デフォルトの結果の表示ラベルもわかりやすく「なし」にします。
３．「ループ」要素でコンテンツドキュメントをループ
2*ありの分岐の先でループ要素を追加します。コレクション変数：２で取得したコンテンツドキュメントレコードコレクション変数
４．ループの中に「割り当て」要素を設定し、コンテンツドキュメントのIdをテキストコレクション変数に追加
レコードコレクションからIdのみのテキストコレクションに変換するような操作です。| 変数 | 演算子 | 値 |
| coll_ContentDocumentIds | 追加 | ループloop_ContentDocuments（③ループ要素のAPI名）の現在の項目 ＞ContentDocument ID |
５．ループを抜けた「最後の項目の後」に「レコードを取得」要素でコンテンツドキュメントリンクレコードを取得
オブジェクト：コンテンツドキュメントリンク条件の要件：すべての条件に一致(AND)
| 項目 | 演算子 | 値 |
| ContentDocumentId | 次に含まれる | coll_ContentDocumentIds |
並び替え順：並び替えなしでも問題ないですが、整理のために「LinkedEntityId」順にしました。
保存するレコード数：すべてのレコード
レコードデータの保存方法：すべての項目を自動的に保存
６．「ループ要素」でコンテンツドキュメントリンクをループ
コレクション変数：５で取得したコンテンツドキュメントリンクレコードコレクション変数７．ループの中に「決定」要素で、添付先が要件のオブジェクトかどうかをチェック
結果の表示ラベル：応募者結果を実行する条件の要件：すべての条件に一致(AND)
| リソース | 演算子 | 値 |
| ループloop_ContentDocumentLinks （⑥ループ要素のAPI名）の現在の項目 ＞リンク済みエンティティ ID | 次の文字列で始まる | 添付先オブジェクトのプレフィックス （レコードIdの固定の頭3桁） |
デフォルトの結果の表示ラベルもわかりやすく「応募者ではない」にします。
８．「応募者（対象オブジェクト）」の分岐の先に「決定」要素を追加し重複をチェック
同じレコードへ複数のファイルをアップロードしている場合に「LinkedEntityId」が重複するのでチェックします。結果の表示ラベル：重複
結果を実行する条件の要件：すべての条件に一致(AND)
| リソース | 演算子 | 値 |
| coll_LinkedEntityIds | 次の文字列を含む | ループloop_ContentDocumentLinks （⑥ループ要素のAPI名）の現在の項目 ＞リンク済みエンティティ ID |
デフォルトの結果の表示ラベルもわかりやすく「重複ではない」にします。
９．重複ではない分岐の方に「割り当て」要素を設定し、最終的に更新するレコードのIDをテキストコレクションに追加
| 変数 | 演算子 | 値 |
| coll_LinkedEntityIds | 追加 | ループloop_ContentDocumentLinks （⑥ループ要素のAPI名）の現在の項目 ＞リンク済みエンティティ ID |
７と８の決定要素は、無くてもエラー無くフローは実行されて想定通りの挙動にはなります。
最終的に処理するIdのコレクションをより綺麗なものにするためにオブジェクトと重複のチェックを入れています。
10*．ループを抜けた先で「決定」要素で更新対象のレコードがあるかチェック
最終的に更新対象のレコードがあるかどうか、テキストコレクションがnullかで確認します。表示ラベル：あり
結果を実行する条件の要件：すべての条件に一致(AND)
| リソース | 演算子 | 値 |
| coll_LinkedEntityIds | null | False |
デフォルトの結果の表示ラベルもわかりやすく「なし」にします。
10．「レコードを更新」要素で添付先レコードを更新
10*「あり」の先でいよいよレコード更新です。更新するレコードを検索してその値を設定する方法：レコードを識別する条件を指定し、項目を個別に設定
オブジェクト：応募者（添付先オブジェクト）
レコードを更新する条件の要件：すべての条件に一致(AND)
| 項目 | 演算子 | 値 |
| Id | 次に含まれる | coll_LinkedEntityIds |
項目値をレコードに設定：
| 項目 | 値 | |
| 添付あり （カスタムチェックボックス項目） | ← | True |
挙動確認
4/11にファイルを添付したところ、4/12 0時にレコードが更新されて添付ありチェックが入りました🙆♀️注意点
このフローはファイルをアップロードした日付（ContentsDocumentのCreateDate）で対象のファイルを決めているため、添付先レコードに【ファイルをアップロード】ではなく、事前に「ファイル」タブでアップロードしておいて、後日【ファイルを追加】から追加した場合、「添付あり」は更新されません。▼4/10にファイルタブやライブラリへアップロード→4/11に応募者レコードへ「追加」→4/12になっても添付ありチェック入らず
ContentDocumentLinkレコードを起点にできれば良いのですが、ContentDocumentLinkはレコード取得時の制限が厳しく、「ContentDocumentIdかLinkedEntityIdが単一のIdと一致する」か、あるいは「Idがコレクション変数に含まれる」の条件指定が必要で、作成日や添付先オブジェクトで取得レコードを絞れません。そのためContentsDocumentを起点にせざるを得ませんでした。
まとめ
個人的には、ユーザが想定外のタイミングや順序でファイルをアップロードすることもあると思うので、今回のスケジュールトリガフローよりも前回記事のように「添付ファイルが必ずなければいけないタイミングでファイル有無をチェックする」方が好みです。その１その２の全2編でお送りしましたが、ファイルまわりで引き続き検証中の内容もあるのでその内その3（画面フローで…）を執筆するかもしれません。
関連記事
レコードのファイルを自動で削除するフローレコード画面からメール送信時の添付ファイルを、そのレコードにも関連づけてファイルを格納したい