子テーブルから新しいフォームを作成におけるエントリー管理者の割り当てルール

各レコードには エントリー管理者 が存在します。ユーザーがエントリーマネージャーになるのは次のいずれかの場合です：

1. レコードを 作成 したとき

2. レコードに 割り当てられた とき

3. 承認フロー に含まれているとき

子テーブルから新しいフォームを作成する場合、子テーブルの各行は 新規シート 上では独立したレコードとして扱われます。

以下の例では、条件によってエントリー管理者がどのように割り当てられるかを説明します。

例：

1. 「プロジェクト」シート（親シート）が存在する。

2. このシートには、複数のプロジェクトタスクを一覧化した子テーブルがある。

3. 子テーブルから「タスク詳細」と呼ばれる新しいシート（新規シート）が生成される。

1. レコード作成者

(1) 親シートでレコードが作成された場合：

子テーブルから新しいフォームを作成した場合、そのレコードは本質的に同じユーザーによって作成されたものとみなされるため、親シートで該当レコードを作成したユーザーが、自動的に新規シート側の対応するレコードのエントリ管理者として割り当てられます。

(2) 新規シートで直接レコードを作成した場合：

レコードを作成したユーザーがそのレコードのエントリ管理者になります。これは関連する親シート側のエントリ管理者には影響しません。

2. 割り当てられたユーザー

独立フィールドで行われた割り当てのみ、ユーザーにエントリー管理者権限を付与します。子テーブルのフィールドでユーザーを割り当てても、対応するレコードのエントリー管理者にはなりません（詳細はこちら）。

子テーブルから新しいフォームを作成した後は、割り当てフィールドの配置場所によって効果が異なります。以下は代表的な 3 つのケースです：

補足：

(1) 新シートでレコードを作成する際に、親シートへアクセス権を持つユーザーを自動的にエントリー管理者にしたい場合は、元フォームのフィールドを新規作成を使用して、親シートの割り当てフィールド（「プロジェクト担当」など）を新シートに追加してください。

これにより、親シートで割り当てられたユーザー情報が新シートにも引き継がれ、そのユーザーが自動的にエントリー管理者として設定されます。

(2) 新規シートで直接作成されたレコードの場合、エントリ管理者は親シートで割り当てられたユーザーにはなりません。ただし、独立フィールド（「プロジェクト担当」）での割り当てを親シート側で更新または再適用した場合、これらの新規レコードのエントリ管理者も更新されます。

3. 承認者

(2) 承認プロセスが新規シートから開始された場合： 承認者は、その新規シート上の該当レコードのみのエントリ管理者になります。