お知らせ：当社は、お客様により充実したサポート情報を迅速に提供するため、本ページのコンテンツは機械翻訳を用いて日本語に翻訳しています。正確かつ最新のサポート情報をご覧いただくには、本内容の英語版を参照してください。

 1. 概要 

多くの企業では、業務を適切に遂行するために、明確に定義されたプロセスが必要です。明確なプロセスがないと、さまざまな課題や非効率が発生します。アプリケーションで業務をデジタル化する場合はなおさら、そのプロセスをワークフローとして徹底することが重要です。ワークフローを設定することで、すべてのユーザーが定められたプロセスに厳密に従うようになり、品質と標準を維持できます。

Blueprint とは 

Blueprint は、ビジネスプロセスフローを視覚的に表現した設計図です。自動化、検証、関係者間のコラボレーションを容易にすることで、組織内のプロセス管理を効率化します。

Zoho Creator では、Blueprint を使用して複数のステージと処理から成るプロセスフローを作成できます。これらの処理はトランジションと呼ばれ、データをあるステージから別のステージへ移動させます。データはフローに従ってステージを進み、最終的に blueprint が完了します。Blueprint を使用すると、Creator アプリケーションで設計するあらゆるプロセスの詳細を柔軟にカスタマイズできます。

たとえば、採用プロセスを blueprint で定義するとします。候補者が応募フォームを送信すると、blueprint が実行され、データは最初のステージApplication Received（応募受領）に入ります。その後、応募内容を評価し、面接対象として絞り込むかどうかを判断します。適格な場合、担当ユーザーはレポート上のShortlistボタンをクリックします。この操作（トランジション）によって、データは次のステージApplication Shortlisted（応募書類選考通過）へ移動します。

この例では、Application Received と Application Shortlisted の両方がステージであり、Shortlist がそれらをつなぐトランジション操作です。下図は、アプリケーションの編集モードにおける blueprint の例です。

有効モードでの動作

アプリケーションの有効モードでは、候補者レポートにおいて、候補者が応募フォームを送信すると blueprint ステータスがApplication Received と表示されます。レポートにはトランジションである Shortlist ボタンが表示され、ユーザーはこれを実行することで、次のステージ Application Shortlisted に進めることができます。

Blueprint がステージごとに進行していき、最後のステージに到達すると、その blueprint は完了となります。   

1.1 ステージ

ステージは、ビジネスプロセスにおけるさまざまな段階やマイルストーンを表します。ステージは、ワークフロー内でのデータの現在の状態を示します。ステージは、次の操作が行われるまでデータが待機するチェックポイントと考えることができます。

例:

• Application Received（応募受領）

• Application Shortlisted（応募書類選考通過）

• Candidate Selected（候補者選定済み）

1.2 トランジション 

トランジションは、ユーザーがデータをあるステージから次のステージへ移動させるために行う処理です。通常、「承認する」「却下する」といったボタンとして表示されます。トランジションにより、プロセスが正しい順序で進み、次のステージへ進む前に必要な処理が確実に実行されるようになります。

例:

• Shortlist

• Confirm Selection（選考確定）

1.3 トランジションの種類 

2 つのステージ間で発生する通常のトランジションに加えて、他にも 2 種類のトランジションがあります。

• 共通トランジション（Common transition）

• 並列トランジション（Parallel transition）

共通トランジション

Blueprint 内の複数のステージから実行できるトランジションを、共通トランジションと呼びます。前述の候補者選考プロセスでは、候補者を却下する操作はプロセスのどのステージからでも行える必要があります。これは共通トランジションを使用することで実現できます。下図の blueprint に示すように、却下する トランジションはすべてのステージから利用できます。

並列トランジション

あるステージから別のステージへ移動するために複数のトランジションが必須となる場合、それは並列トランジションです。一部のビジネスプロセスでは、次のステージへ進む前に複数の手順を踏む必要があります。前述の候補者選考プロセスでは、技術面接と人事面接など、複数の面接が行われるとします。両方の面接に合格した場合にのみ、候補者は次のステージ Interviews Cleared（面接通過） に進むことができます。下図の blueprint に示すように、Passed Technical Interview と Passed HR Interview は並列トランジションです。言い換えると、並列トランジションでは、すべてのトランジションが実行されて初めてデータが次のステージへ移動します。なお、これらのトランジションはどの順序で実行してもかまいません。

情報:

1 つのステージには、1 つの並列遷移しか設定できません（各方向ごとに 1 つまで）。

同様に、1 つのステージに設定できる並列遷移は最大 2 件までです。

メモ: 共通遷移を並列遷移にすることはできず、その逆も同様です。

1。4 ブループリントで遷移を設定する 

遷移では、遷移にアクセスできるユーザー、遷移中に実行する処理、遷移完了後に実行する処理などの設定を行えます。遷移の設定は次の 3 つのパートに分かれています。

• 実行前

• 実行中

• 実行後

実行前

実行前のパートでは、遷移の担当者（オーナー）と条件を設定できます。

• 遷移の担当者は、その遷移を表示して実行できるユーザーです。ブループリント内の各遷移ごとに、個別の担当者を設定できます。1 つの遷移に対して 1 人以上の担当者を設定できます。担当者として、個別ユーザー、権限、ユーザー項目を選択できます。すべての担当者が遷移を実行する必要はなく、いずれか 1 人が実行すればかまいません。

• ユーザー - ユーザーとは、アカウント内のユーザーを指します。アプリケーションに追加された、またはアプリケーションが共有されている個人です。

• 権限 - 権限を選択すると、その権限に関連付けられているすべてのユーザーが、その遷移を表示して実行できるようになります。

• 項目 - 項目とは、現在のレコードのフォームにあるユーザー項目を指します。特定のユーザー項目を遷移担当者として選択すると、レコードのデータに基づいて担当者が動的に割り当てられます。各レコードについて、そのユーザー項目で選択されているユーザーが、その遷移を実行する権限を持ちます。

メモ :

遷移の担当者は、遷移を実行するレコードへのアクセス権を持っている必要があります。

• 遷移の条件では、レコードの項目値に基づいて、遷移ボタンを表示するタイミングをルールとして設定できます。また、OR や AND を使って条件間のロジックを設定することもできます。AND の場合はすべての条件が真である必要があり、OR の場合はいずれか 1 つの条件が真であればかまいません。たとえば、「候補者の年齢が 30 未満」かつ「メールが null ではない」場合に、遷移ボタンを表示するように設定できます。

• ツールチップメッセージ - 遷移ボタンにマウスカーソルを合わせたときに表示されるメッセージを設定できます。

• 確認を要求 - 遷移を実行する前に確認メッセージを表示するかどうかを選択できます。これにより、遷移ボタンをクリックした後にポップアップが表示され、誤って遷移を実行してしまうことを防げます。

遷移ボタン

遷移条件が満たされると、遷移ボタンが担当者に表示されます。

実行中

「実行中」のパートでは、担当者が遷移を実行したときに行う処理を定義できます。次のいずれかを実行できます。

• 同じレコードの項目を表示・更新する - 遷移の実行時に、現在のレコードから選択した項目を表示するポップアップを表示し、担当者にデータの入力を求めます。
  項目を更新すると、フォームに関連付けられている項目更新時ワークフローが既定でトリガーされます。ただし、項目を更新する際に、項目更新時ワークフローの実行をスキップすることもできます。

• 別のフォームを開いて新しいレコードを追加する - このオプションでは、遷移中に表示する別のフォームを選択できます。これにより、任意のフォームに新しいレコードを追加できます。さらに、現在のフォームから選択したフォームへ値を引き継ぐこともできます。引き継がれた値はあらかじめ入力され、フォーム送信前に必要に応じて編集できます。

実行後 

実行後のパートでは、遷移が完了した後に実行する処理を定義できます。利用できる設定は次のとおりです。

• 通知 - 遷移完了後に、次の通知を実行できます。

• メールを送信 - メールを送信します。

• SMS を送信 - SMS メッセージを送信します。

• 通知を送信 - アプリケーションの実行環境内で通知を表示します。

• 完了メッセージを表示 - 遷移完了後にメッセージを表示します。

• URL にリダイレクト - 遷移完了後に、Web サイト、フォーム、レポート、ページなどにリダイレクトできます。

• データアクセス - フォームに対してデータ操作を実行できます。

• レコードを追加 - アプリケーション内の任意のフォームにレコードを追加できます。

• レコードを更新 - アプリケーション内の任意のフォームのレコードを更新できます。

• レコードを削除 - アプリケーション内の任意のフォームのレコードを削除できます。

• 連携 - 次のサービスにレコードを追加できます。

• QuickBooks

• SalesForce

• Zoho CRM

• Zoho Recruit

• Deluge スクリプト - 遷移完了後に Deluge スクリプトを実行します。

これらの設定を使用すると、シンプルな更新から複雑な連携まで、Blueprint の機能を拡張できます。

2. 動作を確認する

  

3. 利用例  

患者管理アプリ

ある医療機関が、患者から検体を採取し、その結果レポートを患者に提供する診断検査サービスを提供しているとします。現在、検査の予約からレポートの提供までの流れは手作業で処理されています。このため、遅延や伝達ミス、その他の運用上の課題が発生しています。

この課題を解決するために、提供者は Zoho Creator の Blueprint を導入し、構造化されたプロセスと自動化された一連の手順を定義しました。Blueprint は検査フォーム内の各検査データに関連付けられ、検査データの開始から終了までのライフサイクルを明確に定義します。Blueprint には、予約済み、検体採取済み、検体受領済み、レポート追加済み、およびレポート準備完了といった複数のステージがあります。また、検体採取の確定、検体受領、レポート追加、レポート確認といった遷移が、これらのステージ間に追加されています。

Blueprint の機能

• 各遷移には、遷移オーナーを設定することで、検体採取スタッフ、検査技師、医師など、異なるロールを割り当てることができます。例えば、レポート確認の遷移は、レポートを確認する医師のみが実行できます。これにより、適切なユーザーだけが該当する処理を実行できるようになります。

• 検査技師がレポート追加の遷移を実行すると、検査レポートフォームが開き、検査結果の値を直接入力できます。

• 医師がレポートを確認し、最終ステージであるレポート準備完了に更新すると、自動メールが顧客に送信され、検査レポートが添付されます。これにより、手動でのフォローアップが不要になり、タイムリーな連絡が保証されます。

このように、全体のワークフローが効率化され、手作業が削減されて生産性が向上しました。

従業員の経費精算プロセス

次に、組織内の給与経費精算プロセスを考えてみます。従業員はフォームを送信して精算申請を行います。給与チームは申請内容を確認し、承認または却下します。給与チームが確認する際、遷移のタイミングで、申請ステータス、承認金額、コメント、却下理由などの項目を更新する必要がある場合があります。これは、項目を更新オプションを遷移中に設定することで実現できます。現在のフォームから選択した項目を、遷移実行時にポップアップフォームとして表示できます。

申請内容の確認が完了すると、承認金額の振込処理のために財務チームへ回付されます。これは、該当する遷移の権限を財務チームのみに設定することで実現します。この遷移が行われるとき、財務チームは「銀行振込」という別フォームに、新しいデータを追加できます。その際、従業員 ID、メールアドレス、承認金額など、現在のフォームの値を引き継ぐことができます。これは、フォームを開くオプションを遷移中に設定することで実現でき、遷移時に別フォームを表示し、現在のフォームから値を渡すことができます。

4. ナビゲーションガイド

前提条件: Blueprint はフォームに関連付けられ、フォーム内の各データに対して実行されるため、Blueprint を作成する前にフォームが必要です。

アプリケーションの編集モードに移動し、メニューバーのワークフローをクリックします。Blueprintsタブで、Blueprint を作成できます。

5. Blueprint のその他の情報 

5。1複数の Blueprint 

1 つのフォームに対して複数の Blueprint を設定でき、それらは優先順位の順に順次実行されます。つまり、Blueprint 一覧ページに表示されている順番で、1 つずつ実行されます。ドラッグ＆ドロップで並び替えることで、実行順序を変更できます。

5.2 Blueprint 項目 

Blueprint 項目は、各データに対する現在の Blueprint の詳細を保持するシステム項目です。これらの項目は、レポートの列として使用したり、レポート作成時のフィルター条件やワークフローの条件として使用したりできます。これらの項目はフォーム上には表示されず、Deluge や UI 操作から更新することはできません。

Blueprint 項目は以下のとおりです。

• Blueprint。名前 - データが現在関連付けられている Blueprint の名前を保存します。

• Blueprint。Current_Stage - データの現在のステージを保存します。データが Blueprint を抜けた場合、その時点でのステージが現在ステージの値として保持されます。

• Blueprint。ステータス - データの Blueprint 内での現在の状態を示します。次のいずれかのステータスになります。

• 有効 - データが現在 Blueprint 内で進行中であることを示します。

• 完了 - データがすべてのステージを通過し、Blueprint を正常に完了したことを示します。
  メモ: 一度データが完了とマークされると、同じ Blueprint に再度入ることはできません。Blueprint に新しいステージや遷移を追加しても、完了とマークされたデータには適用されません。

• Suspended - データが Blueprint から強制的に終了されたことを示します。これは次のような場合に発生します。

• Blueprint を無効にした場合

• Blueprint 内のステージを削除した場合

• ステージを終了ステージとして更新した場合
  上記のすべてのケースで、その時点で Blueprint 上「有効」だったすべてのデータは Suspended とマークされます。

5.3 Deluge タスク 

Blueprint 項目は Deluge からも利用でき、Blueprint 名、現在のステージ、ステータスなどの詳細をスクリプト内で直接参照できます。また、changeStage や executeTransitionといった Deluge タスクを使用して、データをステージ間で移動したり、遷移をトリガーしたりすることもできます。詳細については、Deluge Blueprint ヘルプページを参照してください。

メモ: 追加の Blueprint 変数をサポートするため、Deluge における Blueprint 属性の形式が一部変更されました。これらの Blueprint 属性の更新は、段階的にユーザーへ展開されています。

 

何が変更されましたか?
これまでは、現在の Blueprint ステージには次の変数でアクセスしていました	input。Blueprint_stages
今回の更新後は、この変数は自動的に次の変数に置き換えられます	input。Blueprint。Current_Stage
追加された新しい属性
input。Blueprint。名前	現在の Blueprint の名前を返します。この Blueprint にデータが含まれています。
input。Blueprint。ステータス	Blueprint のステータスを返します。
.DS ファイルのインポートに関する重要なメモ 次のコードを含む .DS ファイルをインポートすると、input。Blueprint_stages、以下のエラーが発生します。 項目 'Blueprint_Stage' does not exist in form これを回避するには、修正した .DS ファイルをインポートする前に、Blueprint_stages のすべての記述を Blueprint。Current_Stage に更新してください。 詳細については、Blueprint 属性のヘルプドキュメントを参照してください。

5.4 レコードと Blueprint の関連付け 

レコードが Blueprint と関連付けられるのは、次のいずれかの場合です。

• レコードが 追加または編集 される際に、UI 操作で手動入力された場合、そのレコードは（該当する場合）完了時ワークフロー が完了した後に Blueprint と関連付けられます。

• レコードが Deluge を介して追加または編集された場合は、現在の実行が完了するか、イベントの終了時に Blueprint と関連付けられます。

• 上記の両方の場合において、レコードがその時点ですでに他の Blueprint と関連付けられている場合は、新たに Blueprint と関連付けられることはありません。

レコードが Blueprint と関連付けられている場合、そのレコードの詳細ビューには、関連するすべてのレポートで共通のストリップが表示されます。このストリップには、レコードの現在のステージと、次に利用可能な遷移が表示されます。表示は、遷移の担当者と定義された条件に基づいて制御されます。

6. 注意点     

• Blueprint は、ポータル 経由で追加されたレコードにも適用されます。

• 1 つのレコードが同じ Blueprint を通過できるのは 1 回のみで、同じ Blueprint に再度入ることはできません。同じ Blueprint への再入を許可すると、同一 Blueprint への割り当てが繰り返される可能性があるため、レコードが次の Blueprint へ進行するよう、再入は制限されています。

• 統計チャートを使用した Blueprint 分析 により、Blueprint の状況を把握できます。

• 既存のレコードは、Blueprint を作成しても自動的には関連付けられません。ただし、それらのレコードが UI または Deluge を通じて更新された場合、（作成時に定義した条件を満たしていれば）Blueprint と関連付けることができます。

7. Blueprint の上限 

8. 関連トピック 

• ブループリントを作成する

• ブループリント クイックスタートガイド