指定アプリに対し、キーに一致するレコードがあれば更新し、なければ新しいレコードを追加します。更新対象のレコードを検索する際のキーの値を、指定レコードのフィールドで指定します。
まず、キーの値を持ちマッピングの元になるレコードを何らかの方法で取得します。例えば「クエリで条件を指定してレコードを取得する」などが使用できます。このレコードを「元になるレコード」として指定します。
「元になるレコード」の「キーの値となる元になるレコードのフィールド」と、「キーとなる更新先のフィールド」が一致する更新先アプリのレコードについて、「マッピング」に基づいてレコードの内容を更新します。
キーの値を持つレコードとして、現在編集画面で編集しているレコードを用いたい場合は、この「レコードをもとに別のレコードを更新または追加する」ではなく、代わりに「レコードを更新または追加する（キーの値をフィールドで指定）」や「レコードを更新または追加する（キーの値を直接指定）」を使用してください。
「追加先アプリ」「キーとなる更新先のフィールド」「元になるレコード」「キーの値となる元になるレコードのフィールド」「マッピング」を設定します。
レコードを更新するアプリを選択します。
レコードを更新する際のキーとなるフィールドを、更新先アプリから選択します。
テーブル内のフィールドは選択できません。
選択可能なフィールドタイプは以下の通りです。
キーの値を持ち、マッピングの元になるレコードを取得したアクションを選択します。
元になるレコードの取得元アプリについて、特に制限はありません。カスタマイズ中のアプリや更新先アプリと同じでも構いませんし、逆にどちらとも違うアプリでも指定可能です。
このレコードは複数行が含まれていても構いません。複数行含まれる場合、その各行に対して順次「キーに一致する更新先レコードを探して、更新する」という処理を繰り返します。逆にレコード件数がゼロだった場合、エラーにはなりませんが、更新対象がひとつもないので処理は行われません。
「元になるレコード」のフィールドの中から、キーとして更新先レコードと比較するフィールドを指定します。
「キーとなる更新先のフィールド」の値と「キーの値となる元になるレコードのフィールド」の値が一致する更新先アプリのレコードが、更新処理の対象になります。
テーブル内にあるフィールドを選択した場合、テーブルの各行に対して処理が行われます。
選択可能なフィールドタイプは以下の通りです。
レコードに登録する情報を入力します。
登録したいフィールド毎に、「登録先フィールドコード = 設定する値」という形で記載します。
このパラメーターの詳しい記述方法はフィールドマッピングの記述方法を参照してください。
このマッピングの式でフィールドコードを指定した場合、そのフィールドは「元になるレコード」のフィールドになります。現在画面で編集中のレコードのフィールドではありません。現在画面で編集中のレコードを参照したい場合は @this を使用します。
このマッピングでは @out を使用することができます。キーに一致するレコードがあった場合、@out はそのレコードを参照します。キーに一致するレコードがなかった場合、@out は空になります。
キーに一致するレコードが存在する場合、そのレコードを上書き保存しようとしますが、その際、更新の競合はチェックされます。
この「やること」と似ている「レコードをもとに別のレコードを更新する」では、更新の競合をチェックするかどうかは設定で選択可能ですが、この「レコードを更新または追加する（キーの値をフィールドで指定）」では競合をチェックしないようにはできません。
一方、キーに一致するレコードが存在しない場合、つまり新規レコードが作成される場合は、競合はチェックされません。
そのため、アクションを２人が同時に実行した場合、同じ内容の新規レコードが２つできてしまう可能性があります。これを避けたい場合、kintone アプリの設定で、キーとなるフィールドの「値の重複を禁止する」をオンにしておくことを強くお勧めします。
追加先アプリに「レコードの追加」条件で Webhook 通知を行うように設定されている場合、本「やること」を実行した結果レコードが追加されると、この通知が発生します。
「やること」の実行結果がレコード追加ではなく既存レコードの更新になった場合は、Webhook 通知は発生しません。