上司・組織責任者を承認者にする

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

申請者ごとに直属上司、上司の上司、所属組織の責任者を求め、固定の利用者名を経路へ並べずに承認者を決められます。

2. Wagby11で実現できること

佐藤さんの直属上司を鈴木さん、主所属を東営業部、東営業部の責任者を高橋さんにします。経路では第1段階を直属上司、第2段階を組織区分「部門」の責任者と指定します。

直属上司はアカウントの上司情報から求めます。組織責任者は主所属から親方向へたどり、指定した組織区分のコードに最初に一致するグループの責任者を使います。主所属自身がその区分に一致すれば、そのグループが対象です。

両段階は申請者を基準に決定します。「直属上司→部門責任者」は、前段の承認者の上司を求める意味ではありません。必要な主所属・上司・責任者などがなければ申請を止め、別の人へ自動で置き換えません。

組織の責任者を設定することと、業務データの参照権限を与えることは別です。担当者の有効区分・閲覧権限や自己承認にならないことも確認します。組織変更だけで進行中の担当者は変えず、再申請では最新情報から決定します。

3. AIへの指示例

最小限の指示例

申請者の上司と部門責任者を、自動で承認者にしてください。

AIは主所属の使い方、部門を表す組織区分、承認の段階を類推して補います。上司と部門責任者が異なる人か、兼務をどう扱うかも具体例で伝えます。

より詳細な指示例

佐藤さんの直属上司は鈴木さん、主所属は東営業部、東営業部の組織区分はDEPARTMENT、責任者は高橋さんとします。備品申請の経路では第1段階を申請者の直属上司、第2段階を申請者の主所属からたどるDEPARTMENTの責任者にしてください。組織情報と担当者条件の両方を準備し、申請確認で2人を確認します。
既存の定義・データ・権限を保持し、Wagby11のguide・referenceを確認してください。利用者向け操作マニュアルを更新し、生成・ビルド後に該当する利用者の画面とAPIで動作を確認してください。

4. 編集されるAppSchemaの例

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

entity:
  workflow: { enabled: true }
permissions:
  - { role: G_SEC_EDITOR, crud: [C, R, U] }
  - { role: G_SEC_MANAGER, crud: [R] }

AppSchemaは対象モデルのワークフローと必要な参照権限を定義します。アカウントの主所属・直属上司、グループの親・組織区分・責任者、経路の担当者条件は運用情報として管理します。

5. 参考資料

承認経路と条件

designer/docs/appschema/html/guide/14-workflow/02-routes.html

モデルの準備

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

組織情報とワークフロー

designer/docs/appschema/html/guide/appendix/08-organization-workflow.html