Gluegent Flow活用例：決裁金額に応じて承認／決裁を切り替えるには？

Gluegent FlowはG Suite(旧Google Apps）やOffice 365と連携し、クラウド上で様々なワークフローを実現できるサービスです。ご導入頂いているお客様では既に様々な「お金」に関するワークフローをご利用いただいていることでしょう。
一般的には上長の承認・決裁が必要な稟議書、精算書などに関するものがほとんどかと思いますが、そのようなワークフローにおいて決裁金額に応じて処理を切替えたいという御要望をお受けすることがあります。
今回は、Gluegent Flowを使って決裁額に応じた承認ルートの分岐方法をご説明します。

決裁金額に基づく承認ルートの分岐方法

本記事では以下の稟議フローの一部を使って説明していきます。
例えば、申請者からの稟議申請に対して直属の上司である課長が承認・決裁する場合、その決裁額によって以下のように処理が分かれるものとします。

20万未満：課長による決裁ができる。
20万以上：承認のみ。決裁の判断は次の承認者・決裁者に委ねる。

課長は決裁金額に応じて承認者となる場合もあれば、決裁者になる場合もあります。

これは、決裁金額によってどちらか一方の処理を排他的に実行するものと考えることができます。

Gluegent Flowでは上記のようなケースを実現する場合、必要な処理を実行するボタンを追加し、そのボタン毎に有効／無効または表示／非表示の条件設定を行うことで、表現することができます。
以下、このボタン表示切替に必要な設定方法を説明します。

経路毎に必要な処理を追加する

ボタン表示制御のためのスクリプトを指定する

例えば、「決裁」ボタンは入力フォームの項目「決裁金額」が20万未満の場合のみ表示するようにしたい場合、以下のようなスクリプトを記述します。

// 決裁ボタンの表示制御用スクリプト
// 20万未満の場合、表示(true)
if ( ${決裁金額} < 200000 ) {
    return true;
} else {
    return false;
}

同様に「承認」ボタンにも表示制御用スクリプトを指定します。承認ボタンの場合は上記のスクリプトとは逆の条件判定になります。なお、スクリプトを記述したら、「スクリプトを確認する」リンクをクリックし、動作検証を行いましょう。

// 承認ボタンの表示制御用スクリプト
// 20万以上の場合、表示(true)
if ( ${決裁金額} >= 200000 ) {
    return true;
} else {
    return false;
}

指定すると、各ボタン名に以下のようなアイコンが表示されます。

以上の設定内容を踏まえたモデル「稟議書」を作ってみました。以下のスクリーンショットでは「費用または金額」が決裁金額に該当するものとします。

例えば、申請者がタブレット購入額として160,000円を稟議申請した場合、20万未満となりますので、課長承認時には以下のように決裁ボタンのみ表示します。

パターンA：決裁金額が20万未満の場合（→決裁）

一方、申請者がノートPC購入額として360,000円を稟議申請した場合は、決裁金額が20万以上となりますので承認ボタンのみ表示します。

パターンB：決裁金額が20万以上の場合（→承認）

以上の通り、決裁金額による条件判定でボタンが切り替わることがお分かりいただけたと思います。

ボタン表示制御を利用するメリット

Gluegent Flowのボタン表示制御を利用することで以下のメリットを享受できます。

ユーザの誤認識による間違ったボタンの押下リスクが防止できる

画面上に説明や注意書をどれだけ記載したとしても、人はミスする生き物であり、ミスは防ぎきれないでしょう。適切にボタン表示切替を利用することで、余計なボタンを押さず、ミスを防止することができます。

ワークフローを一元管理できる

適切にボタン表示切替機能を指定することで、モデルを複数分ける必要はありません。

ユーザの学習コストおよび情報システム部のサポートコストが下がる

画面のボタン表示もシンプルとなり、ユーザの教育コストおよび情報システム部門のサポートコストも下がることにつながるでしょう。

以上、Gluegent Flowのボタン表示制御機能を利用することで承認経路を変更する方法をご紹介しました。お客様へご説明するとき、「え？スクリプト？難しいんじゃない？」と不安がられることもありますが、書き方を少し覚えていただければ、すぐご活用いただけると思います。またスクリプト形式で記述できるからこそ、様々な条件判定が記載でき、拡張性も高いです。なお、注意点としましては、稟議書のモデルを1本にするために複雑な判定処理を記述してしまうと、ボタン毎に同様の記述が必要となり、修正発生時のメンテナンスが大変になる場合もあります。そのため、運用とメンテナンスを考慮しつつ、モデルを1本にまとめるべきか、分けるべきかご検討いただければと思います。

このブログを検索