トリガーの設定、トリガー・ファンクションの設計にあたっては、次のような事項も考慮してください。
カプセル化：
業務処理規則を1箇所に集中させ、カプセル化するよう設計する必要があります。例えば支払い給与税を計算するトリガー・ファンクションを設計する場合、すべての計算式を1箇所にのみ記述します。これにより、計算方法が変わっても、1箇所だけの改訂で済むようになります。
必要が生じてからの設計：
システム設計の初期段階では、ファンクションの具体的な中身を設計するべきではありませんし、何らかの中身を想定して全体の設計を進めるべきでもありません。逆に言うと、設計工程のどの時点でも、必要になった時点で具体的な中身を決めてよい、ということです。例えば支払い給与税の計算方法は、設計工程の最初に考えるのではなく、社員に関するデータを追加/更新するアプリケーションができあがってからでもかまいません。税額計算のトリガーを作成、定義すれば、作成済みのアプリケーションにも直ちに反映されます。
再利用性：
他のアプリケーションで将来再利用されることも念頭に置いて設計する必要があります。支払い給与税の例では、トリガーは、通常のIBM i NPTデバイスから「社員データ保守」ファンクションを通して、またはPCアプリケーションからLANSA Open機能を通してアクティブ化される可能性があります。
情報隠蔽：
支払い給与税を計算する具体的な処理内容に、「社員データ保守」機能を記述するRDMLプログラムの側から干渉できるようであってはなりません。
「具体的な処理」と「イベント」の分離：
トリガー・ファンクションでは、「イベント」が発生したときに何を行うか(すなわち「具体的な処理」)を定義しますが、イベントが発生した旨を検出する必要はありません。データ辞書に設定されたトリガー・ポイントとトリガー条件により、自動的に検出されます。
