よくある質問
よくある質問
各レコードには エントリー管理者 が存在します。ユーザーがエントリーマネージャーになるのは次のいずれかの場合です：
1. レコードを 作成 したとき
2. レコードに 割り当てられた とき
3. 承認フロー に含まれているとき
子テーブルから新しいフォームを作成する場合、子テーブルの各行は 新規シート 上では独立したレコードとして扱われます。
以下の例では、条件によってエントリー管理者がどのように割り当てられるかを説明します。
例：
1. 「プロジェクト」シート（親シート）が存在する。
2. このシートには、複数のプロジェクトタスクを一覧化した子テーブルがある。
3. 子テーブルから「タスク詳細」と呼ばれる新しいシート（新規シート）が生成される。
(1) 親シートでレコードが作成された場合：
子テーブルから新しいフォームを作成した場合、そのレコードは本質的に同じユーザーによって作成されたものとみなされるため、親シートで該当レコードを作成したユーザーが、自動的に新規シート側の対応するレコードのエントリ管理者として割り当てられます。
(2) 新規シートで直接レコードを作成した場合：
レコードを作成したユーザーがそのレコードのエントリ管理者になります。これは関連する親シート側のエントリ管理者には影響しません。
独立フィールドで行われた割り当てのみ、ユーザーにエントリー管理者権限を付与します。子テーブルのフィールドでユーザーを割り当てても、対応するレコードのエントリー管理者にはなりません（詳細はこちら）。
子テーブルから新しいフォームを作成した後は、割り当てフィールドの配置場所によって効果が異なります。以下は代表的な 3 つのケースです：
| 割り当て位置 | 新規シート のレコードのうち、エントリ管理者として割り当てられる範囲 |
|---|---|
| 1. 親シート の独立フィールド（例：「プロジェクト担当」） | その親シートの子テーブルから生成された 新規シート のすべてのレコード |
| 2. 親シートの子テーブルフィールド（例：「タスク担当者」） | 該当する子テーブル行から生成された 新規シート のそのレコードのみ |
| 3. 新規シート の独立フィールド（例：「タスク担当者」） | その 新規シート の特定のレコードのみ |
補足：
(1) 新シートでレコードを作成する際に、親シートへアクセス権を持つユーザーを自動的にエントリー管理者にしたい場合は、元フォームのフィールドを新規作成を使用して、親シートの割り当てフィールド（「プロジェクト担当」など）を新シートに追加してください。
これにより、親シートで割り当てられたユーザー情報が新シートにも引き継がれ、そのユーザーが自動的にエントリー管理者として設定されます。
(2) 新規シートで直接作成されたレコードの場合、エントリ管理者は親シートで割り当てられたユーザーにはなりません。ただし、独立フィールド（「プロジェクト担当」）での割り当てを親シート側で更新または再適用した場合、これらの新規レコードのエントリ管理者も更新されます。
(2) 承認プロセスが新規シートから開始された場合： 承認者は、その新規シート上の該当レコードのみのエントリ管理者になります。
貴重なご意見をありがとうございます！
