モデルを申請・承認の対象にする

1. このページで伝える機能

業務データにワークフローを組み込み、登録した内容を申請・承認する流れを標準の詳細画面で扱えます。

2. Wagby11で実現できること

備品申請を例にします。申請者が件名・内容・購入金額を登録し、承認経路を選んで申請します。上司や部門責任者が内容を確認し、最後の承認段階で決裁を完了します。

モデルのワークフローを有効にした後、管理画面で承認経路を用意します。AppSchemaで有効にするだけでは、誰が何段階で承認するかは決まりません。

申請は登録者本人が行います。承認者には対象データの参照権限が必要ですが、承認のために業務データの更新権限を与える必要はありません。申請状態・担当者・履歴は共通基盤が管理するため、状態を保存する業務項目を独自に追加する必要はありません。

3. AIへの指示例

最小限の指示例

備品申請に申請・承認の機能を付けてください。

AIは対象モデル、監査項目、申請者と承認者の権限、承認経路を類推して補います。既存モデルを利用する場合は、今の項目や権限を残すことも伝えます。

より詳細な指示例

備品申請WorkflowRequestを、監査設定と予約versionを持つT型モデルとしてワークフローの対象にしてください。登録者本人が申請し、承認者は参照権限で内容を確認できるようにします。主キー・業務項目・既存権限を保持し、生成後に管理画面で承認経路を設定してください。状態保存用の業務項目を追加せず、共通基盤の状態を使います。
既存の定義・データ・権限を保持し、Wagby11のguide・referenceを確認してください。利用者向け操作マニュアルを更新し、生成・ビルド後に該当する利用者の画面とAPIで動作を確認してください。

4. 編集されるAppSchemaの例

以下は関連する定義の抜粋です。構文を覚えなくても、誰がどの条件で申請・承認するかをAIへ伝えられます。

entity:
  name: 備品申請
  name_en: WorkflowRequest
  type: T
  audit: true
  workflow:
    enabled: true
  # 主キー・業務項目・監査項目・予約versionは既存の定義を保持します。

これはモデルのentityに指定する部分の抜粋です。監査に必要なcreatedBy・createdAt・updatedBy・updatedAtや、競合を検出するversionなどの定義も保持します。経路の管理はシステム管理者またはG_WORKFLOW_ADMINを持つ利用者が行います。

5. 参考資料

モデルの準備

designer/docs/appschema/html/guide/14-workflow/01-setup.html

操作と状態・履歴

designer/docs/appschema/html/guide/14-workflow/03-operations.html