SFDC：Apex開発のメリット - Apexトリガとワークフロールールの違いについて

実行順序について

データ作成時や更新時には下記の手順で処理が実行されます。

• 古いレコードをデータベースからロード（または、新しい挿入の初期化）
• 新しいレコードの値で古い値を上書き
• システムの入力規則（商談商品を挿入する場合、システムの入力規則に加えてカスタム入力規則が実行されます）
• すべての before トリガを実行（EE / UE のみ）★
• カスタム入力規則
• レコードをデータベースに保存（しかし、コミットされていない）
• レコードをデータベースから再ロード
• すべての after トリガを実行（EE / UE のみ）★
• 割り当てルール
• 自動応答ルール
• ワークフロー ルール★
• プロセス
• エスカレーション ルール
• 積み上げ集計数式の値の更新（存在する場合）
• データベースのコミット
• コミット後のロジック（メールの送信）

ワークフロールールの場合は入力規則の判定後に実行されますが、Apexトリガの場合は入力規則の判定前にbeforeトリガの処理でデータの更新処理を行うことができます。割り当てルールや自動応答ルールなどの前にも実行できるので業務フローに合わせて柔軟なデータの加工が可能となっています。

項目更新順序の制御について

ワークフロールールの場合、複数の項目自動更新処理があると項目自動更新アクションの実行順序は必ずしも担保されるわけではありません。

Apexトリガの場合は処理順序を細かく制御することが可能です。

特定の処理の合間に新たに処理を追加することが比較的容易となっています。またメンテナンス性を意識して開発することで作成/更新時にどのような処理が行われているかも順序立てて確認することができます。

テストについて

Apex開発でよく言われるのがテストクラスを開発しないといけないから不便ということがあります。更新処理が1つ2つしかないシンプルな機能しか用意しないのであればテストクラスの必要性は低いかもしれませんが、トリガにしろワークフローにしろ運用に合わせてどんどん機能拡張していくことになるはずなのでそのときに、既存機能に影響なく処理を追加できているかを判断する必要があります。

テストクラスが存在することで、設定作業時の考慮漏れ等にすばやく気づくことが可能になるのと、こうしたチェックの仕組みがないとちょっとした更新処理を行う際に動作チェックで一週間必要ですといった状況が発生するので、テストの仕組みを構築できるのはデメリットというよりはメリットの方が大きいと思います。

上記のメリット以外にもそもそも実装バグってる...ってときに開発者が自分で気づくきっかけになったりもします。

値変更後の処理実行について

ワークフロールールの場合、項目更新処理後の結果をつかって再度処理を行う場合は「項目変更後にワークフロールールを再評価する」にチェックを付けることで可能となっています。

この「項目変更後にワークフロールールを再評価する」ですが、再評価により更新処理としては2回実行されることになるので、例えば更新時にレコードを新規作成する処理が存在する場合、本来1件しか作成されないはずの部分が2件作成されてしまうといったケースが発生します。Apexトリガでも実装方法によっては似たような問題が発生してしまいますが、メンテナンス性をきちんと考慮して実装すれば、こうした問題を発生させずに複雑な機能を実現することができます。

まとめ

同じ更新処理でもApexトリガとワークフロールールではできることが異なります。業務に合わせて適切な処理を実装していくのであれば「Apex開発 = NG」という考え方はもったいないと思います。Apex開発が万能ということはありませんが状況に応じて適切に扱えば使いやすいシステムになると思います。

個人的には下記のように使い分けるのが良いと思います。

• データ更新 = Apexトリガ
• データ更新で最後に行いたい処理 = ワークフロールール(項目自動更新)
• メール送信 = ワークフロールール(メールアラート)
• Chatter投稿 = プロセスビルダー

実装内容によっては例外もけっこうあったりしますがだいたいこんな感じです。メール送信はApexから実行するよりもメールアラートから実行するほうが制限に引っかかりにくいです。Chatter投稿はApexで開発するのはけっこうきついと思います。

おまけ

最近「できるかぎり標準で」という意味が「ワークフローなどのノンコーディング = 標準」「Apex = 非標準」というニュアンスで使われている気がしますが、個人的には元々の「標準」の意味とは「リードや商談、ケース」といったSales CloudやService Cloudなどの機能を使おうという意味だった気がします。(数年前、SalesCloudなどの機能が今ほど充実してなかったときはForce.comライセンスでカスタムオブジェクトをメインに実装する方が多かったので。)

今は標準オブジェクトをベースにカスタマイズしていることでMarketing CloudやAnalytics Cloud、Einsteinの機能との連携も利用できるようになるのでカスタムオブジェクトメインよりも標準オブジェクトメインの方が結果的にメリットが大きくなってきています。(AppExchangeなどを利用する際にも標準オブジェクトの利用が前提のものが多々あります。)

必要に応じてデータ入力画面や自動更新の仕組みをApex開発で用意することで標準オブジェクトの仕組みを活用しつつ、ユーザにとっても操作のしやすいシステムを構築できるので、コーディング = 悪と片付けるよりは適切なタイミングでどんどん使っていったほうが、「かゆいところに手が届かないシステム」と言われなくて済むのかなと思います。

参考

自動化ルール、および、Apex トリガーはどのような順番で処理されますか？

項目自動更新アクションの考慮事項

関連