クイックスタート：購買承認ワークフロー
このチュートリアルでは、最小構成の購買申請を使って「アセットの定義 → ワークフローの構築 → 設計チェック → 実行時検証」の一連の流れを完成させます。完了すると、申請者が購買申請を提出し、部門責任者が承認し、高額な購買は財務承認へ進むようになります。
1. 前提条件
開始前に、次の内容を確認してください。
- 現在のアプリケーションに、ステータスが DEVELOPING の編集可能なバージョンがある。
- Applicant、Department Manager、Finance Approver のテストユーザーまたはロールが用意されている。
- 申請者の部門から部門責任者を解決できる。
- プロセスアセットの編集権限とアプリケーションの公開権限がある。
2. フィールドを作成する
Process Designer → Task Configuration → Fields を開き、次のカスタムフィールドを作成します。
| Label | Field Type | 主な設定 |
|---|---|---|
| Applicant Department | Department | 部門を 1 つ選択 |
| Amount | Number | 必要に応じて通貨単位を設定 |
| Category | Select | Hardware、Software、Service |
| Required Date | Date | 日付 |
| Reason | Text Area | 長文テキスト |
| Attachments | Attachment | 必要に応じて件数とファイル形式を制限 |
| Department Review Comment | Text Area | 部門責任者が入力する承認コメント |
| Department Review Result | Select | Approved、Rejected。ワークフローが自動書き込み |
| Finance Review Comment | Text Area | 財務承認者が入力する承認コメント |
| Finance Review Result | Select | Approved、Rejected。ワークフローが自動書き込み |
Field Key はフィールド保存時にシステムが自動生成するため、ユーザーが入力する必要はなく、手動入力もできません。後でワークフロー条件、担当者ルール、TQL を設定するときは、Label から Key を推測せず、エディターに表示されるフィールド候補から選択してください。
タイトル、ステータス、作成者、担当者、作成日時などにはシステムフィールドを使用します。同じ意味のカスタムフィールドを作成しないでください。
Department Review Result と Finance Review Result には既定値を設定せず、申請者や承認者に手動選択させないでください。初期値は空のままにし、対応する Approve / Reject トランジションの Post Function で結果を書き込みます。
期待される結果： Fields 一覧にシステムフィールドと上記 10 個のカスタムフィールドが表示されます。
3. フォームを作成する
承認フォームを Task Type の 4 番目のフォームと誤解しないよう、最初に 2 種類のバインドを理解してください。
- Task Type フォームには Create Form、Edit Form、View Form の 3 つのスロットだけがあります。
- トランジションフォームは Workflow の特定のトランジションにバインドされ、ユーザーが Approve または Reject をクリックしたときだけ開きます。
Task Configuration → Forms を開き、次のフォームアセットを作成します。
purchaseCreate：Create Form。タスク作成時に、申請者がタイトル、部門、金額、カテゴリ、希望日、理由、添付ファイルを入力します。
purchaseView：View Form。申請情報、Department Review Result、Department Review Comment、Finance Review Result、Finance Review Comment を、統一されたタスク詳細として読み取り専用で表示します。この例では提出後の業務フィールド編集を許可しないため、Edit Form にもpurchaseViewを選択します。未完了タスクを申請者が編集できる業務では、purchaseCreateを再利用するか、専用のpurchaseEditを作成します。managerReview：Department Review のトランジションフォーム。申請情報は読み取り専用で、部門責任者は Department Review Comment だけを編集できます。
financeReview：Finance Review のトランジションフォーム。申請情報は読み取り専用で、財務承認者は Finance Review Comment だけを編集できます。
この時点ではフォームアセットだけを作成し、Task Type へのバインドはまだ不要です。ワークフローと権限スキーマを完成させた後、セクション 6 で参照関係をまとめて設定します。
期待される結果： Forms 一覧に purchaseCreate、purchaseView、managerReview、financeReview の 4 つのフォームアセットが表示されます。
4. Step とワークフローを作成する
Task Configuration → Steps で次を作成します。
- Department Review
- Finance Review
Step は複数の Workflow から参照できる再利用可能な業務工程アセットであり、現在のワークフローノードに表示する名前だけではありません。Human Activity を Step にバインドすると、実行時タスクには安定した stepCode が記録されます。これにより、複数 Workflow にまたがるレポート、TQL、処理時間、SLA 統計で同じ業務工程を集計できます。
たとえば、Purchase Approval と Expense Reimbursement の両方に財務承認が必要な場合は、両ワークフローの財務 Human Activity から、ここで作成した Finance Review Step を参照します。すると、2 つのワークフローを横断して Finance Review のタスク件数、平均処理時間、SLA 違反率を集計できます。名前だけが同じ一時ノードをワークフローごとに作成しないでください。共通の Step 識別子がなければ、同じ再利用可能な業務工程として確実に集計できません。
Department Review も同様です。別のワークフローに同じ業務的意味の部門承認工程がある場合は、この Step を再利用します。責任範囲、集計基準、SLA 定義が異なる場合は、異なる業務工程を誤って統合しないよう、別の Step を作成してください。
次に Task Configuration → Workflows を開き、以下を作成します。
- Name：Purchase Approval
- Key：画面ルールに従った安定した識別子（例：
PURCHASEAPPROVAL）を入力します。保存後、表示名を変更するためだけに Key を変更しないでください。 - Category：Procurement
- Allow Revoke：業務要件に応じて有効にします。
キャンバスを次のように構成します。
Start → Department Review → Amount Gateway
├─ 少額 → Approved
└─ 高額 → Finance Review → Approved
Department Review / Finance Review で否認 → Rejected
図の設定は、ルーティング、担当者、フォーム、検証、結果書き込みの 5 つで構成されます。
- Task Type の Create Form に
purchaseCreate、View / Edit Form にpurchaseViewをバインドします。 - Department Review の担当者は Applicant Department から部門責任者を解決します。Finance Review の担当者には Finance Approver ロールを選択します。
- Department Review の承認後は Amount Gateway に進めます。少額側の接続に
Amount < 10000を設定して Approved へ直接進め、高額側にAmount >= 10000を設定して Finance Review に進めます。 - Department Review から出る Approve と Reject のトランジションを選択し、右パネルの Transition Form で
managerReviewを選択します。 - Finance Review から出る Approve と Reject のトランジションを選択し、右パネルの Transition Form で
financeReviewを選択します。 - Show Button を有効のままにし、各トランジションに明確な名前、確認メッセージ、案内文を設定します。
- 承認コメントを必須にする検証を追加します。部門側のトランジションでは Department Review Comment、財務側では Finance Review Comment を検証します。
- Department Review の Approve トランジションに Functions → Set Task Field を追加します。Field Name に Department Review Result、Field Value に
Approvedを指定します。 - Department Review の Reject トランジションに Functions → Set Task Field を追加します。Field Name に Department Review Result、Field Value に
Rejectedを指定します。 - Finance Review の Approve / Reject トランジションにも同じ方法で Finance Review Result を設定し、それぞれ
Approved/Rejectedを書き込みます。
同じ承認フォームを、同一ノードの Approve と Reject の両トランジションにバインドできます。担当者が承認と否認のどちらを選んでも、まず対応するトランジションフォームが開き、承認コメントの入力が求められます。検証を通過してトランジションが成功すると、Set Task Field が実際に選択されたトランジションに応じた結果を自動で書き込みます。最終的に purchaseView がコメントと結果を読み取り専用でまとめて表示します。
Result フィールドを承認者が編集できる Select にしないでください。また、フォームボタンで画面表示を変えるだけの実装にも依存しないでください。保存されるフィールド値と実行された Approve / Reject の経路を一致させるため、必ず対応するトランジションの Functions に結果を設定します。
Conditions、Validators、Functions を設定するときは、エディターに表示される候補からフィールドを選択します。Field Label やシステム生成の Field Key を手動でコピーすると、Designer が正しく解決または再表示できない参照が保存されることがあります。
次の画像は、実際に設定したワークフローです。
期待される結果： ワークフロー保存後に未接続ノードがなく、Start からすべての終了ノードまで完全な経路があります。
Spark CLI のインストールと認証を完了し、Codex 連携または Claude Code 連携をインストール済みであれば、ワークフロー要件を AI に直接説明できます。AI は Spark CLI のセマンティックコマンドを使って、ノードの作成、ルートの接続、Step とフォームのバインド、Conditions、Validators、Post Functions の設定を行えます。
依頼には、対象 App、設計バージョン、ノード、分岐条件、担当者、トランジションフォーム、検証ルール、フィールド書き込みルールを明記してください。例：
spark-sample の現在の DEVELOPING バージョンに Purchase Approval を設定する。
Department Review と Finance Review の Step を再利用する。部門承認後は Amount で
分岐し、10000 未満は直接承認、10000 以上は財務承認へ進める。どちらかの承認で
否認された場合は Rejected で終了する。部門と財務のトランジションにはそれぞれ
managerReview と financeReview をバインドし、承認コメントを必須にする。
Approve / Reject 後は、対応する Review Result に Approved / Rejected を書き込む。
書き込み前に対象 App、バージョン、ワークフロー、完全な変更一覧を表示し、私の確認を
待ってから実行する。最後にワークフローチェックを実行する。
AI による設定は設計レビューの代わりにはなりません。確認前に対象 App、バージョン、ワークフローを検証してください。変更後は Process Designer でグラフィカル構造を確認し、適切な実行環境で実際のユーザー、権限、組織データ、分岐を検証します。コマンドと完全な例については、ワークフローのセマンティック編集を参照してください。
5. 権限スキーマを作成する
初めて権限を設定する場合、空のスキーマから 1 件ずつルールを作成する必要はありません。Data & Permission → Permissions で Import System Default をクリックすると、編集可能な既定の権限スキーマをコピーできます。
インポート後に Configure を開き、付与ルールを確認します。複数の Task Type を区別しやすくするため、Edit でスキーマ名を Purchase Request Permission に変更できます。この例のスクリーンショットでは、インポート時の Default Task Permission という名前をそのまま使用しています。すでに空のスキーマを手動作成している場合は Configure を開き、空状態から同じ既定ルールをインポートできます。
スキーマの各行は、Permission Item + Grant Type + 任意の Grant Parameter から成る付与ルールです。この例では、インポートした既定スキーマに次の主要ルールが含まれています。
| Permission Item | Grant Type | 購買ワークフローでの役割 |
|---|---|---|
| Create Task | System User | サインイン済みユーザーによる購買申請の作成を許可 |
| View Task | Task Creator | Applicant が自分で作成した申請を表示できる |
| View Task | Current Assignee | Department Manager または Finance Approver が割り当てられたタスクを表示できる |
| View Task | Historical Assignee | すでにタスクを処理した承認者が、その後もタスクを表示できる |
| Transition Task | Current Assignee | 現在の担当者だけが Approve / Reject などのトランジションを実行できる |
| Revoke Task | Task Creator | Applicant がワークフロールールに従って自分の申請を取り消せる |
| Log Work | Current Assignee | 現在の担当者が作業時間を記録できる。Approve / Reject の制御には使用しない |
Finance Approver に対して、System Role の View Task または Transition Task 権限を追加する必要はありません。Finance Approver ロールは、Workflow の Finance Review ノードの担当者割り当てに使用します。高額申請がこのノードに入り割り当てが完了すると、実際にタスクを受け取ったユーザーが Current Assignee となり、上表の表示権限とトランジション権限を自動的に取得します。Finance Approver システムロール全体に View Task を直接付与すると、高額分岐の対象タスクだけでなく、この権限スキーマに紐づくすべての購買タスクをロール内の全ユーザーが表示できてしまいます。
提出後も Applicant によるタスク編集を許可する場合は、Edit Task + Task Creator を追加します。特定ステータスで実際に編集できるかどうかは、ワークフローステータスと利用可能な操作でも制御する必要があります。Permission Item、Grant Type、Grant Parameter の実際の候補は、現在のシステムに登録された拡張機能から提供されます。必ず UI の候補から選択してください。
6. Task Type を作成する
Task Configuration → Task Types を開き、次を作成します。
- Task Type Key：
PURCHASE - Task Type Name：Purchase Request
- Category：Procurement
- Default Workflow：Purchase Approval
- Permission Schema：セクション 5 で確認したスキーマを選択します。スクリーンショットでは Default Task Permission を使用しています。
- Create Form：
purchaseCreate - View Form：
purchaseView - Edit Form：
purchaseView
managerReview と financeReview は Task Type にバインドしません。これらは Transition Form により、Workflow の特定のトランジションへすでにバインドされています。
期待される結果： Task Type 一覧に Purchase Request が表示され、完全性チェックに合格し、既定ワークフロー、権限スキーマ、3 つのフォームスロットがすべてバインドされています。
7. 設計をチェックして検証環境を選択する
Designer Overview に戻り、現在の DEVELOPING バージョンを選択して readiness check を実行します。未接続ノード、担当者の欠落、未バインドのアセット、不完全な権限など、ブロック要因を修正します。
構造チェックが完了したら、現在の段階に合わせて検証環境を選択します。
- 迅速な設定や個人デバッグでは、DEV 実行環境を直接開き、現在の DEVELOPING バージョンを検証できます。このクイックスタートではこの方法を使用し、以降のスクリーンショットはすべて DEV のものです。
- チーム結合テスト、正式な受け入れ、リリース前検証では、現在のバージョンと TEST に公開済みのバージョンのアセット差分を確認し、承認後に TEST へ公開できます。TEST への公開は任意であり、このクイックスタートを完了するための前提条件ではありません。
readiness check で検出できるのは構造上の問題だけです。実際の組織データ、ロール、権限、実行データによる検証の代わりにはなりません。TEST を使用する場合の公開手順は、テストと公開を参照してください。
8. DEV で実行検証する
このセクションのスクリーンショットは DEV 環境のものです。準備したテストユーザーで次のシナリオを実行します。
- Applicant として Amount が 10000 未満の購買申請を作成します。Department Manager が承認すると、タスクは Approved に直接進む必要があります。
- Applicant として Amount が 10000 以上の申請を作成します。部門承認後に Finance Review に入り、Finance Approver の承認後に Approved へ進む必要があります。
- 別のタスクを作成し、部門または財務の工程で Reject を選択します。Rejected に進むことを確認します。
- Applicant、Department Manager、Finance Approver で My Created、My Pending、処理済みタスクを確認します。対象ユーザーだけが各タスクを表示および処理できることを確認します。
purchaseViewを開きます。Approve または Reject の実行後、対応する Review Result がApprovedまたはRejectedと表示され、承認コメントに担当者の入力内容が保持されていることを確認します。
完了基準： DEV でタスクを作成でき、担当者が正しく解決され、2 つの金額分岐と否認分岐が期待どおりに動作し、フォーム、権限、承認結果を確認できます。TEST に公開した場合は、TEST でも同じシナリオを繰り返し、公開記録を確認してください。