Salesforce 承認プロセスを利用する前に確認したい５つのこと

この記事では「Salesforceの承認プロセスを利用したい！」と考えている方のために、承認プロセスを利用する前に確認しておきたい“５つのポイント”をご紹介します。

もし海外旅行に行く場合どんなことを確認しますか？
旅行先で必要な金額、移動手段、宿泊場所、保険...こういったことを確認しておけば渡航先でのトラブルを避けることができます。

同様に、Salesforceの承認プロセスを設定する前に自社のSalesforceの運用状況を確認することで、よりスムーズに承認プロセス作成に入ることができます。では、早速見ていきましょう。

これから作成しようとしている承認プロセスはどのようなものでしょうか？

- 経費精算申請の承認プロセス
- 出張申請の承認プロセス
- 商談の値引き承認プロセス

様々な承認プロセスがありますよね？

承認プロセスを作るケースとしては「オブジェクトが既にあり、それに承認プロセスを作る」ことが一般的ですが、申請に合わせてカスタムオブジェクトを作ることもできます。

その時考えなければならないのは、承認プロセスを「オブジェクト別に作る」か「一つのオブジェクトの中で条件分岐させて作る」かを決めることです。

オブジェクト別に承認プロセスを作るのはわかりますが、条件分岐させて作るというのはちょっとわかりにくいですよね。

例えば、次の承認プロセスを作りたい場合はどうでしょう？

- 経費精算申請の承認プロセス
- 書籍購入申請の承認プロセス
- 仮払経費申請の承認プロセス

これら３つのためにそれぞれオブジェクトを作ると、同じような項目や承認プロセスが並びそうですね。

そういう時は、1つのオブジェクトの中に経費精算や書籍購入、仮払経費申請用のレコードタイプや項目を作り、申請時に条件分岐させてそれぞれ異なる承認プロセスを適用させることもできます。

メリット
・オブジェクトに「経費精算オブジェクト」、「勤怠管理オブジェクト」のように名前をつけることができ、わかりやすい。

デメリット
・承認プロセスは同じオブジェクトならコピーして再利用できますが、オブジェクトが分かれるとコピーできません。そのため繰り返しの設定作業が増えます。

・作成できるオブジェクト数に上限があるため、オブジェクトの数(上限はこちら)が足りなくなる可能性があります。

メリット
・ひとつのオブジェクト内で条件分岐させるため、オブジェクト数を節約できます。

・承認プロセスをコピーできるので設定が楽です。

デメリット
・申請内容によって管理項目が様々なので、カスタム項目が不足する可能性があります。

お勧めの方法として、同じような項目や承認プロセスで構築できそうな場合は、一つのオブジェクト内で条件分岐させて作る方が良いでしょう。それぞれのメリットデメリットを踏まえ、自社に最適な構成を選択してみてください。

承認プロセスのためにオブジェクトを作るときは「オブジェクトごとに作る」か「条件分岐させて作る」か、メリットとデメリットを考慮して設計する。

申請開始条件とは、特定の条件を満たすレコードだけを承認プロセスの開始対象としたいとき利用するものです。例えば「この出張経費申請は、本社の社員だけに制限したい。」というようなルールを作りたいケースです。

申請開始条件に利用できる項目は「対象のオブジェクト」「対象の親オブジェクト」「現在のユーザー」オブジェクトの項目です。作ろうとしている承認プロセスの「申請開始条件」がこのオブジェクトの中の項目で利用できるか確認してください。

これらのオブジェクトにない場合はどうしたら良いでしょうか？

私たちがご支援させていただいているケースの中には、これらのオブジェクト以外の参照関係にあるオブジェクトを開始条件として利用するケースが多々あります。

例を見てみましょう。

次の「出張申請オブジェクト」に出張許可を出すための承認プロセスを作りたいです。

申請開始条件は「出張許可者オブジェクト」の申請者レコードに出張許可のチェックフラグがついていることです。

この場合、どうすれば出張申請オブジェクトの承認プロセス開始条件として利用できるでしょうか。考えてみましょう。

例
出張許可者オブジェクトがユーザーオブジェクトと参照関係にあるので、ユーザーオブジェクトに数式項目を作成して出張申請オブジェクトの値を見るようにします。

今回のケースのように申請条件に必要な項目が利用できない場合、参照関係を作り数式で取得することで申請条件として使えます。

申請開始条件でオブジェクトの項目が使えないときは、参照関係と数式で乗り切る。

一般的に承認プロセスは、申請者の上司を承認者として割り当てるものですよね。

承認者を割り当てる場合はSalesforceの階層関係項目と呼ばれる上位のレコードを指定する項目を利用して承認者を自動的に割り当てます。

標準ではユーザーオブジェクトにあるマネージャ項目がそれですね。

Salesforceのユーザーオブジェクトを開いて階層関係項目が利用されているか確認してみてください。

- 階層関係項目は利用していますか？
- 利用していてもメンテナンスされていますか？

これらの項目が利用されてなかったり、メンテナンスされていない場合、承認プロセスを作成する前に最新の階層関係をSalesforceに登録する必要があります。

社長や取締役など階層関係で最上位にいるユーザーが申請する場合はどのように設定しますか。

この場合は階層関係項目が利用できないので、直接ユーザーを指定する承認ステップを作成するという案もあります。ただし、直接ユーザー指定した承認ステップ*を作ってしまうと次のデメリットがあります。

- 承認者が退職等で無効ユーザーになると承認ステップが動かない
- 承認者を変更する場合、以前の承認プロセスをコピーして毎回新たな承認プロセスを作る必要がある

社内で上手に運用できるかどうか検討すると良いと思います。

* 承認ステップとは特定の承認プロセスの承認を定義するものです。

承認者を割り当てる方法が決まったら、次に承認条件について確認しましょう。

Salesforce標準で利用できる承認条件としては

1. 最初の返答に基づいて承認とする
2. 選択したすべての承認者全員の承認を得て承認とする

の２つが承認方法として設定できます。

半分以上、3/4以上の承認という使い方はできません。

会社の承認ルールが半分以上、3/4以上で承認している場合は、1.プログラム開発をするか。2.対応しているグループウェアのアプリ(mitocoならできます)を使ってみるのはいかがでしょうか。

承認者の割り当て方法は階層関係項目を利用するとメンテナンスが楽。承認条件は「最初の返答で承認」とするか。「複数の承認者全員で承認」とするか決めておく。

申請の種類によって申請者を制限したいケースってありますよね？

例えば「経費申請」は全社員、「商談の割引」は営業部門、「稟議申請」は本部長や取締役からのみ...というようなケースです。

承認プロセスごとに申請者を直接指定することもできますが、その場合、設定するのもメンテナンスするのも苦労します。ロールや公開グループを利用すると良いでしょう。

まず「全社員が申請可能な承認プロセス」を作る方法と、次に「特定の社員のみ申請可能な承認プロセス」を作る方法をお伝えします。

特定の社員のみ申請許可する場合には、1. 社員名で指定する 2. ロールで指定する 3. 公開グループで指定するの３つの方法があります。
メンテナンスのことを考えるとできれば「1.社員名で指定する」は使いたくありません。

特定の部署全員を指定していたら...その中のメンバーが移動や退職のたびにメンテナンスするなんて大変ですよね。なのでロールで指定するか公開グループで指定する方法を検討すると良いでしょう。

全員が申請可能なものは「すべての内部ユーザー」を使う。申請者を制限する場合は、目的となる申請者が含まれているロールや公開グループを使うと良いでしょう。

監査証跡とはなんでしょうか？

監査証跡とは、監査人がシステムの処理内容やプロセスを追跡するために時系列で保存されたデータのことです。

監査人に監査証跡としてSalesforce承認済みのデータを見せる時は、承認履歴レポートが便利です。（対応可能かは監査会社によります）

承認履歴レポートを利用することで「何時、どの部署の誰から申請されたのか。」「何時、どの部署の誰が承認をしたのか」という情報を一覧表示させることもできます。

しかし組織の変更等で承認者の所属部署が変更になると、その承認者が承認した、過去の承認履歴の部署と役職欄も変更されてしまいます。

監査証跡として使うにはちょっと困りますね。

監査対象となる承認プロセスを作る場合、これらの情報を保持できる仕組みを検討することをお勧めします。

具体的には承認済みのページをPDFで保存したり、mitocoのような申請者や承認者の承認時点の部署や役職を保存する機能がある製品で対応可能かもしれません。

監査証跡で必要なデータについて関係者に聞いてみる方が良いでしょう。

承認プロセスによっては監査の対象となるものがある。監査の提出物として承認履歴レポートや承認済みのページを印刷して保管しておくことで対応できる場合がある。まずは監査証跡にどのようなデータが必要なのか有識者に確認する。

ご紹介した５つのポイントは確認漏れしやすいところなので、是非参考ください。
確認した結果、承認プロセスの利用が難しいなら、mitocoを検討するのも手です。

mitocoは

- 日本の複雑な商習慣にも対応できるワークフロー
- 複数人での承認条件を半数以上、3/4以上等の指定
- 申請された内容の申請以外への回覧
- 申請された内容の差し戻し
- 申請、承認時点のユーザー情報を保持する監査証跡への対応
等

Salesforceをもっと便利にする機能が揃っています。
これを機にみなさまが承認プロセスを利用してワークフローシステムを活用することを願っています。