前章では、申請承認アプリについての概要を説明しました。本章ではどのような申請ー承認を行えば良いかを設計します。
設計
本アプリでは、「申請者」と「承認者」の二つの立場なので割と単純な構造です。業務アプリでの申請ー承認も基本形はこれだと思いますので参考になると思います。例えば、組織に依らないようなフローを立てる場合には工夫が必要になりそうです。
図解してみました。
まず申請者が申請を行うと、ボールは承認者に渡ります。承認者はボールに対して審議を行い、ボールを申請者に戻します。
- 承認：申請OK。申請者は予算を使って購入ができるようになります。
- 却下：申請NG。却下内容は残り、申請者が閲覧できます。
- 差し戻し：申請に見直しが必要です。
差し戻しが起こった場合、申請者は申請内容を見直し、再申請を行い、ボールは承認者に渡ります。それに対して再度承認者は審議を行う・・・というループを、承認/却下になるまで行うというフローです。
SharePointリストの設計
上記申請承認を行うためのSharePointリストを設計します。申請内容を必須項目とし、後ろに審議内容、購入内容が紐づいてくるような設計にしました。（項目名は英名→日本語名でリネームしています）
| 項目名 | 列の種類 | 内容 | 備考 |
|---|---|---|---|
| 申請日時 | 日付と時刻 | 申請した日時 | 必須入力 |
| 申請者 | ユーザーまたはグループ | 申請したMS365ユーザ情報 | 必須入力 |
| 申請状況 | 選択肢 | 申請状況（アプリで自動入力） | 必須入力 「申請中」「承認済み」「却下」「差し戻し中」「購入済み」 |
| 申請金額 | 通貨 | 申請する金額 | 必須入力 |
| 申請理由 | 参照 | 申請の理由（別リストを参照する選択肢） | 必須入力 「申請理由リスト」を参照 |
| 申請コメント | 複数行テキスト | 理由を補足するコメント | |
| 審議日時 | 日付と時刻 | 審議した日時 | |
| 審議者 | ユーザーまたはグループ | 審議するMS365ユーザ情報 | |
| 審議状況 | 選択肢 | 審議状況 | 「承認」「差し戻し」「却下」 |
| 審議理由 | 参照 | 審議の理由（別リストを参照する選択肢） | 「審議理由リスト」を参照 |
| 審議コメント | 複数行テキスト | 理由を補足するコメント | |
| 購入日時 | 日付と時刻 | 購入した日時 | |
| 購入金額 | 通貨 | 実際に購入した金額 | |
| 購入コメント | 複数行テキスト | 購入を補足するコメント | |
| 予実差異 | 集計値（他の列を基にした計算結果） | 予算（申請額）と実績（購入額）との差 | [申請金額]-[購入金額] 種類は 通貨 |
| 更新日時 | 日付と時刻 | 内容が更新された最終日時 | 自動生成 |
| Attachments | （添付ファイル） | 添付ファイルを保持 | 自動生成 |
全てを賄うようにしたので、項目は多めになっています。今回、見慣れない列の種類を使用しています。ユーザーまたはグループです。
「申請者」について、実際にSharePointリストに入った内容を確認してみます。ぱっと見、申請者名が入っていますが、カーソルを申請者名に近づけると、このようにMS365アカウントの情報が表示されます。ということで、ユーザーまたはグループには名前が入っているのではなく、MS365アカウント情報が入っています。利点は、組織のアカウント以外は登録できないので組織に沿った入出力ができるということです。「上司」「部下」の紐付けができているのであれば、適切な呼び出しができます。欠点は扱いに癖があることです。PowerAppsの開発時詳しく説明します。
| 項目名 | 列の種類 | 内容 | 備考 |
|---|---|---|---|
| ID | （システム生成） | 自動付番されるID | アプリ使用時の並び順に使用 |
| 理由 | 一行テキスト | 理由の選択肢に使用 | 理由を入力 |
申請理由と審議理由は別のマスタとして用意してあります。選択肢として作るにはテキストが長く、のちのメンテナンス性も悪いためです。
以上でSharePointリストの設計完了です。PowerAppsの開発に移ります。
次のステップ
次章からPowerAppsの開発です。今回はPowerApps生成のアプリではなく、空のアプリから作成していくので、まずは空のアプリとSharePointリストを紐づける際の注意部分を中心に展開していきます。
コメント