フローの命名ルールを決めて迷わず実装＆仲間にもわかりやすくしよう
移行ツールもリリースされていますが、ずべてのワークフロー＆プロセスに対応しているわけではないし、フローへの理解を進めるためにも自分でフローを覚えて作り直したほうがいいかな、と個人的には思います。
ワークフロールール＆プロセスビルダーでやってきた人が躓くところって、フローでは細かくリソースや要素を自分で定義していかなくてはならないところもあるのではないでしょうか。
……現に私がそうだからです。自由は不自由。自由には自分が決めて自分で結果を受け止める責任がありますよね。大げさですが、フローを触り始めたころ、よく考え見つけました。
Salesforce業界で統一されたルールがあればいいのかもしれませんが、あまり縛り過ぎると独自の工夫もしにくくなるかもしれません。難しいところですが、「これからフロー頑張る予定です」という方へ、ヒントとなるページを見つけましたので、共有いたします。
個人的な感想として「なるほど、ここも区別したほうがいいな」と勉強になった部分もありましたが、理解するにはちょっと時間がかかるかもしれません。
ベストプラクティス（英語記事）も参考に
今回の内容は、フローを構築する前に一読しておきたいベストプラクティスについて最近アップデートされた（2023年2月14日更新）公式さんのブログで紹介されていたページを日本語訳したものです。◇ salesforce admin ＞Article ＞The Ultimate Guide to Flow Best Practices and Standards
近々こちらの記事の日本語版も紹介したいと思っています。
今回は命名ルールについて書かれたところだけ引用します。
Ensure consistent naming across elements and variables↓日本語訳です。
Stick to naming conventions when creating variables and elements in Flow. Include in the variable description what you’re capturing. A little bit of work upfront will go a long way for future ‘you’ or somebody else that inherits the flow. There’s no right or wrong way to do this; just keep it consistent within the flow. One popular naming convention is called CamelCase. Check out this nifty Wiki article from the Salesforce Exchange Discord Server on suggestions for flow naming.
要素や変数に一貫した命名ができるようにする
フローで変数や要素を作成する際は、命名規則に従うこと。変数の説明には、何を捕捉しているのかを含める。フローを継承する将来の「あなた」や「他の誰か」にとって、前もって少し手間をかけておくことは、大きな意味を持ちます。この方法に正解や不正解はなく、フロー内で一貫性を保つだけです。一般的な命名規則として、キャメルケースというものがあります。フローの命名に関する提案については、Salesforce Exchange Discord Server の Wiki の 記事を参照してください。
こちら↑でリンクされているWikiの記事を、日本語訳してみました。
開発の方の話も入っているので、そちらに明るくない方には見慣れない言葉もあると思います。というか私がそうです。↑でも書かれているように、すべてをこのとおりにする必要はないので、参考情報としてお読みください。
◇ SFDC Wiki ＞ブック ＞Best Practices ＞Flow Conventions ＞Flow Naming Conventions
フローの命名規則
画面のサブ要素以外の接頭語はすべて大文字とする。接頭辞の後の名前はすべてキャメルケースで、指定された場所以外ではアンダースコアはありません。下部の表は、ほとんどの場合の例を示しています。参考：●わくわくBank ＞IT豆知識 ＞命名規則(キャメルケース, パスカルケース, スネークケース, ケバブケース)
メタ・フロー・ネーミング
1.フロー名は常に、その起源となるドメイン名で始まり、その後にアンダースコアが続くものとするほとんどの場合、フローのドメインは、それがホストされているオブジェクトと同等である。
構造的な慣習として、クロスオブジェクトのフローは避けるべきであり、クロスオブジェクトの操作を行うフローを同期させるためにイベントに依存することが必要である。
2.ドメインの後には、以下のようなケースを考慮し、常にフローのタイプを示すコードが続くものとする。
1.フローが画面フローである場合、コードはSCRとしなければならない。
2.フローがサブフローである場合、コードはSFLとしなければならない。
3.フローがバッチで実行されるスケジュールされたフローとして特別に設計されている場合、コードはBATとしなければならない。
4.フローがレコードトリガーフローである場合、コードはTRGとしなければならない（SHALL NOT）。
さらに、フロー名には、BEFOREまたはAFTERを意味する実行コンテキストを含め、Create、CreateUpdate、またはUpdateのいずれかを続けなければならない。
5.フローがイベントトリガーフローである場合、コードは代わりにEVTとしなければならない。
6.フローがメール送信のみを処理するレコードトリガーフローとして特別に設計されている場合、コードはその代わりにEMLとしなければならない。
3.フロー名は、さらに、可能な限り正確な方法で実行されるアクションにちなんで命名されなければならない。レコードトリガーフローの場合、これは何がトリガーになるかに限定される。詳細については、例の表を参照のこと。
4.フローの説明は、フローが実行するために必要なもの、機能的に行うもの、および出力するものを常に示すべきである。
| 種類 | 命名 | 説明 |
|---|---|---|
画面フロー | QUOTE_SCR_AddQuoteLines | 見積行追加画面を上書きするための画面フローです。Discounts_cmtdに基づく割引計算に関する機能を提供する。 |
スケジュールフロー | CONTACT_BAT_SendBirthdayEmails | 毎日実行され、取引先責任者に誕生日メールが送信されるかどうかをチェックし、Marketing_Birthdayというテンプレートを使って送信するスケジュールフロー。 |
取引先上のBefore-Update（高速項目更新）フロー | ACCOUNT_TRG_BeforeUpdate | アカウント更新前の自動化をトリガする。 |
取引先上のAfter-Update（アクションと関連レコード）フロー | ACCOUNT_TRG_AfterUpdate | 取引先にAfter-Updateの自動化をトリガする。SFL_Accのフローを確認し、アクションを実行。 |
商談上のレコードトリガフロー商談が成立したらアクションが実行されるような、商談が終了したら実行されるイベント、 | OPP_TRG_BeforeUpdate | 商談にBefore-Updateの自動化を発動させる。 |
イベントトリガフロー,請求書作成のような、商談が終了したら実行されるイベント | INVOICE_EVT_SalesFinished | 請求書を作成し、請求書発行に新しく通知して、売上情報に基づいて検証する。 |
取引先上の、メール送信を行うフロー | ACCOUNT_EML_BeforeUpdate | レコードの変更に基づく取引先からのメール通知を処理。 |
フロー要素
DMLｓ(データ操作言語)1.クエリは、オブジェクトの場合はGet、CMTD や Settingsの場合はFETCHで開始しなければならない。
2.更新は常にUpdateで始まり、アンダースコアが続くものとする。コレクションを更新する場合、前述のアンダースコアの後にListを付けるものとする。
3.作成は、常にCreateの後にアンダースコアを付けて開始しなければならない。それがコレクションを作成する場合、アンダースコアの後にリストによって接頭されなければならない。
4.削除は、常にDelfで始まり、アンダースコアが続くものとする。コレクションを削除する場合、アンダースコアの後にリストによって接頭されなければならない。
種類 | 命名 | 説明 |
|---|---|---|
フロー内の画面 | ラベル: 価格表エントリを選択 API参照名: S01_SelectPBEs | 価格表をもとに、見積書に追加する商品を選択できるようにする。 |
フロー内のDMLに基づくエラーを処理する画面 | ERROR_GET_PBE | 価格表エントリの取得に失敗すると発生する。おそらく権限に関係していると思われる。 |
フローの最初の画面のテキストコンポーネント | S01_T01 | 要素から実際のテキストを入力。説明項目はなし。 |
フローの最初の画面のデータテーブルコンポーネント | S01_LWCTable_Products | LWCが説明項目を提供しないかもしれないので、適用できないかもしれない。 |
相互関係
1.画面は、常にSで始まり、現在のフローにおける画面の数に1を加えた数に対応する番号が続き、その後にアンダースコアが続くものとする。
2.アクションは、常にACTで始まり、アンダースコアが続くものとする。アクション名は、さらに、そのアクションが何を実行するかを示すべきである。
・APEXアクションは、常にAPEX insteadで始まり、アンダースコアが続き、期待される結果の短縮形が続くものとする。適切に命名されたAPEX関数は、そのまま命名に使用できるはずである。
・サブフローは、常にSUBで始まり、アンダースコアが続き、トリガーされたフローのコード（例：FL01）が続き、アンダースコアが続き、期待される結果の省略形が続くものとする。
5.メールアラートは、常にEAで始まり、アンダースコアが続き、送信されるメールテンプレートのコード、アンダースコア、送信されるべきメールの略語が続くものとする。
画面要素
1.どのような変数も、常にvarで始まり、アンダースコアが続くものとする。
・コレクションを格納する変数は、常にcollで始まり、アンダースコアが続くものとする。
・レコードを格納する変数は、常にsObjとアンダースコアで始まるものとする。
・その他の変数タイプは、常に追加で、変数タイプのインジケータとアンダースコアで始まるものとする。
2.数式は、常にformの後にアンダースコアが続き、その後に返されるデータ型とアンダースコアが続くものとする。
3.選択肢は、常にchの後にアンダースコアを付けて開始しなければならない。選択肢の名前は、選択肢の結果を反映する必要があります。
種類 | 命名 | 説明 |
|---|---|---|
販売した商品の総数を求める計算式 | formula_ProductDiscountWeighted | 商品の種類によって割引を加算し、実際の最終的な割引額を計算する。割引や価格のNULL値をキャッチし、0を返す。 |
"recordId"を格納するための変数 | recordId | フローを開始するレコードIDを格納。 Salesforceのレガシーな動作のため、通常の規約からは除外されている。 注：この変数名はCASE SENSITIVEです。 |
コレクション変数に格納する前に、ループ内のフローで計算された値から作成したレコード | sObj_This_OpportunityProduct | 計算した商談商品の値。 |
マネージャの画面。変数と画面要素の例。
ロジック
1.決定がオープンな選択肢である場合はDEC、論理的な終端である場合はCHECKで始まり、アンダースコアが続くものとする。アクション名にはさらに、Is、Can、または決定の性質を示す他の副詞と、チェックされる内容についての短い説明を前置すべきである。・決定結果は、接頭辞のない決定名で始まり、アンダースコアが続き、その後に結果が続くものとする。
・デフォルトの結果は、エラー処理に使用されるべきであり、該当する場合はERRORと再ラベルする。
2.割り当ては、常にSET、ASSIGN、STORE、REMOVE、CALC（実行される割り当てのタイプによる）で始まり、アンダースコアが続くものとする。
・SET は、変数の更新に使用されるべきで、主にオブジェクト変数に使用される。
・ASSIGN は、変数の初期化、または非オブジェクト変数の更新に使用される。
・STOREは、コレクションに要素を追加するために使用される。
・REMOVEは、コレクションから要素を削除するために使用される。
・CALCは、数学的な割り当てや複雑なコレクション操作に使用される。
3.ループはLOOPで始まり、アンダースコアが続き、繰り返し処理されるものの説明が続くものとする。これはコレクション名と異なる場合がある。
種類 | 命名 | 説明 |
|---|---|---|
計算した商談商品のレコード値を設定するための割り当て。 | SET_OppProdValues | 計算された割引と数量に基づいて、商談商品を設定する。 |
後で作成する商談商品をコレクション変数に格納するための割り当て | Name: STORE_ThisOppProd | 算出された商談商品ラインをコレクション変数に追加して作成。 |
コレクションに格納された複数のレコードを作成するDML sObj変数 | CREATE_OppProds | 設定された商談商品を作成。 |
| Decision: CHECK_PBESelected | 少なくとも1つの行が選択されているかどうかをチェックする。そうでない場合は、エラー画面に終了する。 |
基準に基づいて要素をソートすることを決定する | Decision: DEC_SortOverrides | ユーザの選択に基づいて、レコード内の情報を上書きする必要があるかどうか、どの情報を上書きする必要があるかを確認する。 |
フローから請求書の受け取りを知らせるアラートメールが送信される。 | EA01_EI10_InvoiceReceived | 請求書の詳細を記載したテンプレートEI10を送信する。 |
ひとこと
日本語で書かれたサイトだと、やっぱりこちらでご紹介されているのがわかりやすいと思います。◎Salesforce Flow Recipes ＞実装時に気をつけると良いこと
（とてもお世話になっております！）
読んだだけ内容がわかるようにすることも大事ですが、細かすぎてもルールの徹底が大変ですよね。どこまでを命名ルールでカバーするか、説明欄を大いに活用するのか、是非関係者で相談してみてください。
私、お客様に提出するときは緊張感をもってルールに気をつけるのですが、自分のために検証していると大変適当なのです。すみません。一貫性のあるフローのプロを目指すためにも、いま一度管理しやすいルールを整理して、それに基づいてやっていこうと思います。
フローの記事あれこれ
Winter23 フローの関連レコードの更新が少し変わるよ（プロセスビルダーに似てるよ）【フロー】複数ルックアップコンポーネントを使って商談一括作成画面を作ってみた
フロー画面でのレコードタイプによる選択リストの絞り込みを試してみた
毎月N日に起動させるフロー
レコードのファイルを自動で削除するフロー
フローを食わず嫌いしている人へ
実験：フローで取引先を【関連情報と共にコピー】してみた
フローで積み上げ集計（その１）
Spring’23 画面フローで複数選択リストをいつもの入力画面のように設定できます。
Spring'23 フローの参照項目でレコードが作成できます
Spring’23 フローの対話型コンポーネントを使用した画面の構築って何？
ワークフローからの卒業：日付項目を過ぎた子レコードの数を把握②フローで日付が過ぎたらレコードを更新
入力しやすさと集計どちらも叶えたい！5段階評価を画面フローで入力する
保留にしている承認者へリマインダーメールを送信したい
リストビューで選択したレコードを一括削除してみる
ワークフローのFlow移行ツール：Migration to Flow（Beta）を試してみました
担当レコードへのChatter投稿はメンションされなくても通知を受け取りたい
ワークフローからの卒業：ロングテキストエリア入力有無をフローで確認 値の削除にも対応編
カスタムオブジェクトから参照する標準オブジェクトを更新するフローは再編集時エラー出るけれど動くそう