フォームデータの入力は作業の終わりではなく、ワークフローの始まりです。

なぜ重要なのか

ほとんどのクリエイティブ承認ソフトウェアでは、フォームは入力フィールドです。ユーザーがフォームに入力すると、データはデータベースに送信され、ワー​​クフローは独自のロジックで実行されます。フォームデータは、せいぜい参照資料であり、最悪の場合は完全に分離されています。

Aproove では、フォームをワークフロー自体のフロントエンドとして扱います。フォームで取得されたデータは、ルーティングの決定、ステークホルダーの割り当て、自動化されたアクション、および下流の動作を推進するデータです。「プロジェクト キックオフ」フォームは、プロジェクトを要求した人を記録するだけでなく、ワークフローにどのアカウント マネージャーを割り当てるか、どのブランド テンプレートを適用するか、どのコンプライアンス パスウェイに従うか、どの期限を守るかを指示します。フォームはハンドルです。

これは、運用上 2 つの理由で重要です。

1 つ目、プロジェクト マネージャーはデータ入力の仲介者ではなくなります。要求者は、受付時にプロジェクト コンテキストを一度入力します。ワークフローはそれをすべて継承します。従来、プロジェクトマネージャーがプロジェクトごとに20分を要していた手動設定（ステークホルダーの割り当て、期限の設定、ルーティングの設定）が、フォーム送信自体に集約されます。

2、受付時に取得したデータは、プロジェクトの期間中はもちろん、その後も利用可能です。リクエスターがプロジェクト開始フォームに入力したメールアドレスは、ワークフローが6ステップ後に承認済みファイルをリクエスターに送信する際に使用するメールアドレスと同じです。同じブランドコードがダッシュボードのフィルターになります。同じプロジェクトカテゴリがレポートのディメンションになります。一度取得すれば、どこでも使用できます。

仕組み

フォームの設計 管理者は、管理ツールでレイアウトグリッドにフィールドを追加してフォームを作成します。各フィールドには、タイプ（テキスト、ドロップダウン、日付など）、検証ルール（必須、書式制約）、およびオプションのメタデータマッピングがあります。フォームの外観と権限は、対象ユーザーごとに構成されます。

フォームコレクション 単一のフォームでは不十分な場合は、複数のフォームをコレクションにグループ化できます。管理者はフォームの順序を設定し、コレクション内の各フォームに対して、前のフォームで入力された値に基づいてフォームを表示するかどうかを決定する PHP eval 式を記述できます。一般的なパターンとして、フォーム 1 のチェックボックスで「その他」にチェックを入れると、フォーム 2 に「その他」テキストフィールドが表示されます。チェックを入れない場合は、そのフォームは完全にスキップされます。

メタデータの保存 フィールドの値は、プロジェクト レベル（またはフォームによってはタスク レベル）でメタデータとして保存されます。メタデータは、ワークフロー ルーティング、トリガーとアクションの自動化、ダッシュボード 列の表示、検索フィルター、レポート生成など、Aproove のすべてのサブシステムで使用できます。

ワークフローの統合 フォームはワークフロー ステップに接続して、適切なタイミングで起動できます。「プロジェクト承認」決定ボタンに添付されたフォームは、プロジェクトを進める前にアカウント マネージャーに「作業指示」フォームを表示します。フォーム データによって、次に実行されるワークフロー ブランチが決定され、キャプチャされた値に基づいてまったく異なるワークフローがトリガーされることもあります。

タスク アクセス フォーム コレクションは、Proof Information ポップアップを通じてタスク内で公開できます (デフォルトでは読み取り専用)。これにより、外部のゲストやプロジェクトの詳細権限を持たないユーザーは、より広範なアクセスを許可することなく、タスクに関連するプロジェクト コンテキストを表示できます。

アドホック タスク フォームは、構造化されたワークフローの外で、単発のタスク作成に使用できます。ユーザーが基本的な「臨時タスク」フォーム（受信者、期限、指示）を入力すると、システムは受信者のToDoリストにタスクを作成します。タスクが完了すると、依頼者に通知されます。

メリット

• フォームデータがワークフローを推進します。 取得された値は単に保存されるだけでなく、後続の作業を積極的にルーティング、割り当て、構成します。
• 一度取得すれば、どこでも使用できます。 受付時に入力されたメールアドレスは、承認時にも使用されます。ブランドコードはダッシュボードのフィルターになります。同じデータポイントが、すべての下流用途に使用されます。
• フォームコレクションを使用すると、複雑な受付処理がスムーズに行えます。 複数のステップからなる受付プロセスは、1つの圧倒的なフォームではなく、条件付きロジックを備えた順序付けられたフォームに分割されます。
• 必須フィールドにより、データの完全性が確保されます。 ワークフローの実行に必要なデータがないと、プロジェクトを開始できません。後続のステップでのクリーンアップ作業は不要になります。
• フォームは作業とともに移動します。 フォームコレクションは、ゲストやプロジェクトへの完全なアクセス権を持たないユーザー向けにタスク内でアクセス可能にできるため、外部の関係者はより広範な権限付与なしに、必要なコンテキストを確認できます。
• 同じワークフローで多くの構成に対応できます。 フォームデータによってルーティングが決定されるため、1つのワークフローテンプレートで、フォームが取得する内容に応じて数十のプロジェクトバリアントに対応できます。‍
• 中間者によるデータ入力は不要です。 プロジェクトマネージャーは、依頼者が既に提供したデータを再入力する時間を費やす必要がなくなります。フォームの送信自体が構成となります。

対象者

• 組織の受付プロセスを設計する承認管理者。
• 大量のプロジェクト受付を運営し、一貫したデータ取得が下流の処理能力を左右するマーケティングおよびクリエイティブオペレーションのリーダー。
• 監査およびトレーサビリティのために構造化されたデータ取得を必要とするコンプライアンスおよび規制管理者。
• 顧客対応チーム（アカウントマネージャー、プロジェクトコーディネーター、カスタマーサービス）クライアントまたは社内依頼者からの受付を処理する。
• プラットフォームがプロジェクトマネージャーをデータ入力の中間者の役割に強制するか、依頼者が独自の受付を主導できるようにするかを評価するオペレーションリーダー。

内部構造

カスタムフォームは、フィールド値がプロジェクトまたはタスクレベルでメタデータとして保存される、構成可能な入力レイアウトです。フィールドの種類には、自由入力、ドロップダウン、ルックアップ、日付、ブール値、ファイルアップロードなどがあります。フォームは、プロジェクトの作成時、ワークフローのステップ内、決定ボタンの有効化時、またはスタンドアロンのアドホックタスクの作成時にトリガーできます。フォームコレクション（2025 R2でリリース）は、PHP evalベースの可視性式を使用して複数のフォームをシーケンスし、前のフォームに入力された値に基づいてコレクション内のどのフォームを表示するかを決定します。必須フィールドは、フォーム間の「次へ」ボタンを制御します。フォームコレクションは、プルーフ情報ポップアップを介してタスク内で読み取り専用として公開でき、プロジェクトの詳細にアクセスできないライセンスユーザーと外部ゲストが、タスクに関連するフォームを表示できるようにします。フォームでキャプチャされたメタデータは、実行時変数置換のためにトリガーとアクションで使用できます（入力時に入力されたリクエスターのメールアドレスは、手動構成なしで下流の自動通知の受信者アドレスになります）。ダッシュボードは、フォームメタデータを構成可能な列として表示できます。レポートでは、フォームのメタデータをフィルタリングやグループ化のディメンションとして使用できます。フォームで取得したメタデータ値に基づいてルーティングすることで、同じワークフローで多くの異なるプロジェクトバリアントに対応できます（「大規模なスマートルーティング」を参照）。