テクサポ日本 6月27日 14:05 の記事の転載です。
個別に記事に直接アクセスできないので...

Apex CPU time limit exceeded のエラーについては、Salesforce のプラットフォームの制限である、Apex ガバナ制限の内、「Salesforce サーバの最大 CPU 時間」に抵触した場合に出力されるものです。
Apex ガバナ制限は “Apex” という名前こそついてますが、プラットフォームの制限でございますためフローやプロセスの処理も対象となります。
「Salesforce サーバの最大 CPU 時間」では同期処理 (通常のフロー／プロセスの処理) では処理時間が 10 秒まで、非同期処理 (スケジュール実行される処理等) では 60 秒までという制限があります。
そのため、設計が複雑になっている等で処理時間がかかる場合には当該のエラーが出力される場合があります。

また、先日の Summer ’22 の更新では、フローとプロセスで CPU 時間がより正確に測定されるようになる更新がありました。
ご参考：フローおよびプロセスの CPU 時間消費の正確な測定 (リリース更新)

そのため、Summer ’22 からフローやプロセスで Apex CPU time limit exceeded のエラーが出るようになったというお客様もいらっしゃるのではないでしょうか。

フローやプロセスの処理でどのくらい CPU 時間を利用しているかは、デバッグログから確認することができます。
以下ではフローやプロセスでデバッグログを取得する方法についてご案内させていただきますため、こちらの方法によりデバッグログを取得いただき、CPU 時間を使いすぎている複雑な設計がある場合には見直しすることをご検討いただけますと幸いです。

フロー／プロセスのデバッグ用のデバッグレベルの作成

1．[設定] 画面左側メニューの検索バーに [デバッグログ] と入力しデバッグログ画面へ移動します。
2．ユーザ追跡フラグセクションの [新規] ボタンをクリックします。
3．デバッグレベル項目の [新しいデバッグレベル] をクリックします。
4．カテゴリ：[ワークフロー] のレベルを [より詳細] に変更し、任意の名前を付けて保存してください。

デバッグログの設定

5. 上記設定が完了しますとデバッグレベルに４で作成したデバッグレベルが設定された状態となります。

引き続き以下の情報を設定し [保存] ボタンをクリックします。

追跡対象エンティティ種別：ユーザ
追跡対象エンティティ名：フローを実行するユーザ (虫眼鏡アイコンから検索して設定ください)
開始日：デバッグログを取得開始する任意の時間
有効期限：デバッグログの取得を終了する任意の時間
デバッグログの取得

6. 上記状態でフロー／プロセスを実行します。
7. デバッグログ画面に対象のフロー／プロセス実行時のログが表示され、ダウンロードが可能となります。

一例ですが、デバッグログでは以下のようにログが出力されます。

デバッグログより抜粋 (サンプル)

FLOW_START_INTERVIEW_LIMIT_USAGE|CPU time in ms: 23 out of 15000
FLOW_INTERVIEW_FINISHED_LIMIT_USAGE|CPU time in ms: 31 out of 15000

FLOW_START_INTERVIEW_LIMIT_USAGE と、FLOW_INTERVIEW_FINISHED_LIMIT_USAGE を確認することで、当該のフロー／プロセスがどのくらい CPU 時間を使っているかを確認することができます。

上記サンプルでは対象のフロー自体では 8 ミリ秒の CPU 時間を使用していることがわかります。

エラー

Apex CPU time limit exceeded. Data volume 400

Please check this article.

https://help.salesforce.com/s/articleView?id=000387833&type=1

False,False,,"[{'statusCode': 'CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY', 'message': 'npsp.TDTM_Contact: System.LimitException: Apex CPU time limit exceeded', 'fields': []}]"

簡単に言えば、問題は多かれ少なかれ自然に解決しました。サーバーの速度低下の直接の原因はわかっていますが、何が起こったのか、なぜ突然修正されたのかについては十分な説明がありません。これは、SFDC サポートと数週間協力することで実現しました。

基本的な問題は、サーバー上に 550 個の npsp トリガーがあったことです。サーバー上の数値を確認するには、開発コンソールで「select count(Id) from npsp__Trigger_Handler__c」を実行します。 NPSP には通常、トリガーが 55 個しかありません (新しいサンドボックスがある場合は、NPSP 設定に移動するまでトリガーが 0 個になる可能性があります)。これらすべてのトリガーがどのように作成されたのかはわかりませんが、これらすべてを使用するとインポートに問題が発生するのは明らかです。最初に問題が発生してから数週間後にサンドボックスを更新したとき、トリガーは再び正常になり、過去に同じレベルの問題が発生したことはありませんでした。

このプロセスの早い段階で、より大きな問題を理解する前に役立った他の 2 つのことを行いました。

インポートによってトリガーされるいくつかのスケジュールされたロールアップで DLRS をオンにしました。スクリプトを数回実行した後、スケジュールされた DLRS ロールアップが約 100,000 件ありましたが、実行されていませんでした。それが作業を大幅に遅らせていました。
スクリプトによって直接関係したいくつかの DLRS ロールアップをオフにし、インポートが完了したら完全な再計算でそれらを再アクティブ化します。

問題が完全に解消されたとは言えません。今朝インポートを行ったところ、かなりの数のエラーが発生しましたが、以前よりも大幅に減りました。

"'CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY', 'message': 'Apex トリガが存在する場合、バッチ保存の再試行が多すぎて失敗します: トリガが存在する場合、部分保存では、行の一部のサブセットがエラーなしで保存される必要があり、それらによる矛盾した副作用を避けることができます。トリガーの数: 2'、'フィールド': []}]""