PlatoForms User Guide
Ctrl+K
  • Form Builder

    Creating an Online Form for an Existing PDF

  • Custom Domain

    With Builder you can build three types of forms: online web forms, online PDF forms, and master forms.

  • Master Form Builder

    you will arrive at the Form Builder. On the form Builder, there are three main sections:

ワークフローの例

以下の各例は、描くべき形状、重要な設定、および関係者が経験することを示しています。これらは互いに基づいて構築されているため、たとえ4番目を求めている場合でも最初の2つを読んでください。

2ステップの署名

最もシンプルなワークフロー: 顧客がフォームに入力し、マネージャーが同じPDFに署名します。

顧客フォーム ──▶ マネージャーが署名

構築方法

  1. PDFから顧客のフォームを作成し、その後、マネージャーのコピー用にPDFファイルを再利用してクローンを作成し、署名以外のすべてのフィールドを削除します。両方を公開します。
  2. 顧客フォームを開始ステップとして追加し、パレットでフォームをクリックしてマネージャーのフォームを選択します。
  3. マネージャーステップで: 通知タブ、これらのアドレスに送信: マネージャーのメール。データ & PDFタブ: ステップ間でデータを結合をオンにして、署名が顧客のPDFに印刷されるようにし、必要なら署名証明書を作成します。
  4. 開始ステップで: 誰が返信を受けるか: 顧客のメールを保持するフィールド。
  5. ワークフローパネルで、実行が完了したときに誰に通知されるか: ワークフローを開始した人に送信をチェックして、顧客が署名済みのPDFを受け取るようにします。

何が起こるか。 顧客が送信します。マネージャーはリンク付きのメールを受け取り、それを開いて顧客のデータをPDFで確認し、署名します。顧客は署名済みのPDFが添付された完了メールを受け取ります。

返送付き承認

マネージャーが承認し、修正のために返送するか、却下するリクエスト。

リクエストフォーム ──▶ マネージャー承認 ──✓──▶ 終了「承認済み」
      ▲                 │
      └───────✗─────────┘   (返送はリクエストを再開します)

構築方法

  1. リクエストフォームを追加し、その後承認ステップを追加します。承認タブで誰が承認するか?: マネージャーをチームメンバーとして、またはリクエストのメールフィールドから選択します。
  2. 承認の赤い返送ドットをリクエストフォームに戻します。パネルは今、「リクエストフォーム」を編集用に再開と表示されます。
  3. 緑の承認済みドットの後に終了ステップを追加し、「承認済み」と名前を付けます。
  4. 決定ボタン: 承認返送を保持するか、却下を追加して返送としてカウントするように設定します。コメントを要求して、リクエスターが理由を学べるようにします。
  5. リクエストフォームで誰が返信を受けるか: リクエスターのメールフィールド。

何が起こるか。 マネージャーのリンクにはリクエストPDFと選択したフィールドが表示され、ボタンが表示されます。承認は実行を完了します。返送はリクエスターにコメントと提出へのリンクをメールで送信します。リクエスターはそれを修正して再送信し、承認が再度実行されます。返送ドットを接続せずに残した場合、返送は実行を終了し、リクエスターは許可された場合、事前入力されたコピーで再開始できます。

承認後に署名する承認者

マネージャーが承認し、その後1回のセッションでドキュメントに署名します。

フォーム ──▶ 承認 ──✓──▶ 署名 (承認した人)

構築方法

  1. 上記のようにフォームと承認を追加します。
  2. 承認タブで、承認後の下にある承認者用のフォームを追加をクリックし、署名フォームを選択します。タブには「承認者が次に“署名”を入力」と表示され、署名フォームの通知タブには**“承認”を承認した人に送信**がチェックされています。
  3. 署名フォームのデータ & PDFタブでステップ間でデータを結合をオンにします。

何が起こるか。 承認ページの承認ボタンには承認して続行と表示され、その下のメモには「承認後に“署名”を入力」と書かれています。マネージャーは承認し、署名フォームに直接移動します。同じリンクを含むメールも送信され、ブラウザを閉じた場合に備えます。署名は同じPDFに入り、リクエスターの完了メールには署名済みのドキュメントが含まれます。承認決定メールは署名が存在する前に決定時に送信されます。

並行する2人の承認者、1つの署名済みドキュメント

2人のマネージャーが両方とも承認し、同じPDFに署名する必要があり、どちらも他の決定を待つべきではありません。

        ┌──▶ 承認A ──✓──┐
フォーム ───┤                    ├──▶ 署名A ──▶ 署名B ──▶ 終了
        └──▶ 承認B ──✓──┘   (すべてを待ちます)
        署名A: Aを承認した人
        署名B: Bを承認した人

構築方法

  1. フォームを追加し、その後フォームの出口ドットから接続された2つの承認ステップを追加し、それぞれのマネージャー用に1つずつ設定します。「承認A」と「承認B」と名付けます。
  2. 承認Aで、承認後 → 承認者用のフォームを追加: Aの署名フォームを選択します。それはAの承認済みパスに表示され、Aに宛てられます。
  3. 承認Bの緑の承認済みドットを署名Aにドラッグします。署名Aには2つの入力接続があり、すべてを待つを保持します。
  4. 承認Bで、承認後 → 承認者用のフォームを追加: Bの署名フォームを選択します。それは署名Aの後に配置され、Bに宛てられます。
  5. 両方の署名フォームでステップ間でデータを結合をオンにします。

何が起こるか。 AとBは同時に、任意の順序で決定します。2番目の決定が署名Aを解放します: Aが最後に決定した場合、Aはそれに直接進みます。そうでない場合、Aはメールでそれを受け取ります。Aが署名すると、署名BはメールでBに送信されます。両方の署名は1つのPDFに入り、署名Bは署名Aの出力に印刷され、元のものに印刷されます。

これが取ることができる形状

人々は同じ要件をいくつかの方法で描きます。すべてが機能し、誰が待つか、何枚のドキュメントが出るかが異なります。

形状 並行して決定 ドキュメント 選ぶとき
AとBの1つの承認、全員が承認する必要がある、1つの署名フォーム はい 1つ 1つの署名で十分: 承認を完了した人がグループのために署名します。
承認Aと承認Bが並行して、署名Aと署名Bが順番に (上記) はい 1つ 両方が同じドキュメントに署名する必要がある。これは推奨される形状です。
承認A → 署名Aと承認B → 署名Bが別々のパスに はい 2つ 各承認者が自分のドキュメントに署名し、自分自身の証明を行います。各署名フォームは元のものに別々に印刷されるため、完了メールには最後に提出されたものが含まれます。
フォーム → 承認A → 署名A → 承認B → 署名B いいえ 1つ Bの決定はAのものに依存するべきであり、階層的に。

1つの署名フォームに2つの承認がチェックされると、最初に開いた人が請求する共有タスクが作成されますが、これは2つの署名が必要な場合にはほとんどありません。チェックリストはそれについて警告します。

回答によるルーティング

小額の購入はチームリーダーに、大額のものはディレクターに送られます。

購入リクエスト ──▶ ブランチ ──[金額が5000を超える]──▶ ディレクター承認 ──✓──▶ 注文フォーム
                       │                                                                   ▲
                       └──[それ以外]────────────────────────▶ チームリーダー承認 ──✓──────┘

構築方法

  1. リクエストフォームの後にブランチステップを追加し、その後2つの承認を追加し、各ブランチ出口ドットをそれぞれに接続します。
  2. ブランチを選択します。ディレクターのパスのカードで、ルールを追加: フィールド金額、比較より大きい、値5000。もう一方のカードはそれ以外です。
  3. 注文フォームを追加し、両方の承認の承認済みドットをそれに接続します。ここに複数のパスが到達したときの下で最初のものを続行を選択します: 実行ごとに1つのパスのみが取られます。

何が起こるか。 12,000のリクエストはディレクターに送られ、800のリクエストはチームリーダーに送られます。どちらの場合も承認されたリクエストは注文フォームに到達します。2番目のルールを追加する場合は矢印でカードを並べ替えます。最初に一致するパスが勝ちます。

並行する2つの部門、その後の最終レビュー

HRとITがそれぞれ独立して自分の部分を記入し、両方が完了した後にコーディネーターがレビューします。

        ┌──▶ HRフォーム ──┐
インテーク ─┤              ├──▶ コーディネーターレビュー (すべてを待ちます)
        └──▶ ITフォーム ──┘

構築方法

  1. インテークフォームの後にHRフォームとITフォームを追加し、インテークの出口ドットから接続します。各通知タブで受信者を指定します。
  2. レビューステップを追加し、両方のフォームをそれに接続します。すべてを待ちますを保持します。
  3. レビューが続行するべきPDFを持つフォームからの接続を選択し、このパスのPDFと回答をベースとして使用をチェックします。両方のフォームが独自のPDFを持っている場合、レビューで前のステップのPDFへのリンクを含めるを使用して、コーディネーターがもう一方を開けるようにします。チェックリストは、1つのパスのPDFのみが続行されることを思い出させます。

何が起こるか。 HRとITは同時にメールを受け取ります。両方が提出したときにのみコーディネーターのタスクが作成されます。それまでトラッカーは遅れている部門を待っている実行を表示し、実行のドロワーはそのパスを色付けします。

繰り返されるステップ

承認された旅行、その後に任意の数の経費請求が続きます。

旅行リクエスト ──▶ マネージャー承認 ──✓──▶ 経費請求 (再提出可能) ──▶ 財務レビュー

構築方法

  1. 以前の例のようにリクエストと承認を構築し、その後に経費請求フォームと財務レビューを追加します。
  2. 経費請求ステップで、ルールタブで同じリンクを再提出に使用できるをチェックします。

何が起こるか。 旅行者は1つのリンクを受け取ります。最初の請求後、リンクには提出済み別の提出ボタンが表示されます。各請求は独自の財務レビュータスクを作成し、トラッカーはそれぞれをリストします。このオプションがない場合、リンクは最初の請求後に閉じ、署名や申請に適しています。

Is the content helpful?