いまこの記事をご覧いただいている皆様は、おそらく Salesforce の承認プロセスをご利用になっている、もしくはご利用を検討されていて、何かしらお悩みを抱えており、その解決策を探していらっしゃると思われます。
本記事では、その解決策について考察してみたいと思います。
本記事では、その解決策について考察してみたいと思います。
よく耳にする、代表的なお悩み例を挙げてみましょう。
- どのような申請を回すのかの選択ができない
- 異なる種別の申請を同時に回せない
- どのような承認が下りたのか、履歴から読み取れない
- どのような承認ルートで申請が回るのかが見えない
Salesforce の承認プロセスはご存知の通り、各オブジェクトのレコード情報を元にして申請を回す作り(オブジェクト起点)になっていて、一般的なワークフローシステムと少々異なった仕組みになっています。この「オブジェクト起点」というところが、上記のようなお悩みが発生する要因の1つにもなっています。
かといって、もっと構築しやすい別のワークフローシステムを導入すればいいのでしょうか?
答えは「ノー」です。
別のワークフローシステムを導入すると、今度は情報の二重管理や同期といった課題が発生してしまいます。
せっかく Salesforce に情報が集約されているわけですから、その情報を活用しない手はありません。
そこで、お悩み発生の原因となっている「オブジェクト起点」をメリットに変えて、 Salesforce ならではのワークフローシステムを構築する方法を模索してみましょう。
答えは「ノー」です。
別のワークフローシステムを導入すると、今度は情報の二重管理や同期といった課題が発生してしまいます。
せっかく Salesforce に情報が集約されているわけですから、その情報を活用しない手はありません。
そこで、お悩み発生の原因となっている「オブジェクト起点」をメリットに変えて、 Salesforce ならではのワークフローシステムを構築する方法を模索してみましょう。
申請用のカスタムオブジェクトを利用する
例えば、取引先に対して「反社チェック申請」を行いたい場合、素直に実装しようと考えたら取引先の承認プロセスを作成すると思いますが、そうしてしまうと前述の通り、どのような(取引先レコードの、どの項目値に対して)承認申請が行われたのかがわからなくなってしまう、というお悩みが発生してしまいます。
その解決方法として、申請用カスタムオブジェクトの利用を推奨します。
その解決方法として、申請用カスタムオブジェクトの利用を推奨します。
申請用カスタムオブジェクトを利用すれば、「反社チェック申請」に必要な申請情報は取引先ではなく申請用カスタムオブジェクトに項目として持たせることができるようになります。
そして、申請用カスタムオブジェクトを利用する最大のポイントは、申請用カスタムオブジェクトにもともと承認を回したかったオブジェクト(取引先など)の参照項目を作ってリレーションを張ってあげることです。
これにより、申請用カスタムオブジェクトが取引先などの明細として管理できるようになります(1対nのリレーション構築)。
そして、申請用カスタムオブジェクトを利用する最大のポイントは、申請用カスタムオブジェクトにもともと承認を回したかったオブジェクト(取引先など)の参照項目を作ってリレーションを張ってあげることです。
これにより、申請用カスタムオブジェクトが取引先などの明細として管理できるようになります(1対nのリレーション構築)。
この方法を採用すると、取引先ではなく明細(申請用カスタムオブジェクト)側にレコードタイプを持たせることができるようになるため、別種の申請が増えた場合の管理もスマートです。
もちろん、申請時の入力画面も複数用意できます。
もちろん、申請時の入力画面も複数用意できます。
その他にも、申請承認のエビデンスとなるファイルも申請用カスタムオブジェクトレコード側に添付できるようになるなど、メリットはたくさんあります。
AppExchange の活用も選択肢に加える
申請用カスタムオブジェクトを使うことで、「どのような申請を回すのかの選択ができない」「異なる種別の申請を同時に回せない」「どのような承認が下りたのか、履歴から読み取れない」というお悩みは解決できることがご理解いただけたかと思います。
では、「どのような承認ルートで申請が回るのかが見えない」というお悩みについてはどうでしょうか?
残念ながら、 Salesforce の承認プロセスでは、ユーザが承認ルートを確認する手立ては用意されていません。
そこで、検討に加えてほしいのは、 AppExchange の活用です。
では、「どのような承認ルートで申請が回るのかが見えない」というお悩みについてはどうでしょうか?
残念ながら、 Salesforce の承認プロセスでは、ユーザが承認ルートを確認する手立ては用意されていません。
そこで、検討に加えてほしいのは、 AppExchange の活用です。
AppExchange では、いくつかワークフローアプリケーションが提供されています。
テラスカイからも mitocoワークフローというアプリケーションを提供していますので、 mitoco を例に取ってお悩み解決方法を解説いたします。
テラスカイからも mitocoワークフローというアプリケーションを提供していますので、 mitoco を例に取ってお悩み解決方法を解説いたします。
mitoco は、承認プロセス(承認フロー)の設定と利用時の UI を独自機能で提供しており、「承認フローの可視化」が標準装備されています。
そのため、申請者はどのようなルートで承認が回るのか、どのような分岐条件が入っているのか、ということを事前に理解してから申請できますし、申請中もどこで滞っているのかをひと目で確認することができます。
そのため、申請者はどのようなルートで承認が回るのか、どのような分岐条件が入っているのか、ということを事前に理解してから申請できますし、申請中もどこで滞っているのかをひと目で確認することができます。
その他にも、 mitoco ワークフローには「差し戻し」や「多数決」、Apex 承認ロジックの呼び出しなど、 Salesforce の承認プロセスにはない機能がたくさん搭載されています。
mitoco ワークフローでさらなるメリットを享受する
mitoco ワークフローには、実は申請用カスタムオブジェクトが最初から用意されています。
mitoco の申請用カスタムオブジェクト(「申請データ」オブジェクト)は、もともと mitoco オリジナルの UI でワークフローを回せるように用意されているものですが、カスタム項目やレコードタイプ、ページレイアウトなどの追加が可能ですので、ご自身で申請用カスタムオブジェクトを用意するのと同様の機能実装が可能です。
mitoco の申請データは唯一 mitoco オリジナルの UI から操作できるオブジェクトですので、さまざまな種類の申請(取引先の NDA 申請、商談の値引き申請、etc…)を前述の手法で運用していれば、取引先に関する申請や商談に関する申請といった種別をまたいだ一覧管理ができます。例えば承認者で mitoco の「処理待ち」一覧を見て、上から順に処理していくといった使い方をするときに大変便利です。
mitoco の申請用カスタムオブジェクト(「申請データ」オブジェクト)は、もともと mitoco オリジナルの UI でワークフローを回せるように用意されているものですが、カスタム項目やレコードタイプ、ページレイアウトなどの追加が可能ですので、ご自身で申請用カスタムオブジェクトを用意するのと同様の機能実装が可能です。
mitoco の申請データは唯一 mitoco オリジナルの UI から操作できるオブジェクトですので、さまざまな種類の申請(取引先の NDA 申請、商談の値引き申請、etc…)を前述の手法で運用していれば、取引先に関する申請や商談に関する申請といった種別をまたいだ一覧管理ができます。例えば承認者で mitoco の「処理待ち」一覧を見て、上から順に処理していくといった使い方をするときに大変便利です。
「取引先 + mitoco ワークフロー」利用イメージ
文字ばかりでは実際にどんな使い方ができるのか分かりづらい思いますので、利用イメージの動画を用意しました。
前半は申請者目線、後半は承認者目線となっています。
前半は申請者目線、後半は承認者目線となっています。
申請者:
- 取引先レコードにアクセス
- 「反社チェック申請」をクリックして反社チェック申請情報登録
- 登録した反社チェック申請情報にエビデンスとなる文書を添付し、「申請・承認」をクリックして mitoco ワークフロー申請画面を開く
- 申請ルートを確認し、コメントを入れて申請実行
承認者:
- mitoco 通知で申請依頼を受け取る
- 通知をクリックして承認用画面を開く
- 申請時コメントを確認
- 添付ファイルを承認用画面からプレビュー確認し、コメントを入れて承認実行
via
www.youtube.com
申請用カスタムオブジェクト方式を採用する場合の考慮事項
メリットの多い申請用カスタムオブジェクトの利用ですが、考慮事項も挙げておきたいと思います。
自社組織へ実装する場合はこれらをご認識のうえ、検討・検証してください。
自社組織へ実装する場合はこれらをご認識のうえ、検討・検証してください。
考慮事項 | 対応方法 |
---|---|
親オブジェクトレコード(取引先等)のロックができない | 入力規則とレコードタイプ&ページレイアウトの組み合わせでカバーするなどの工夫が必要だが、そもそも親をロックする必要があるのかどうか考える。(申請レコードはロック可能) |
「親(取引先等)の作成→子(申請レコード)の作成→申請実行」と、真ん中のステップが1個増える | 最適化のための必要な手間と考える。画面構成を工夫して動線を整える。SkyVisualEditor で親子一括登録画面を実装するなど、 AppExchange も解決のための 1 つの選択肢に加える。 |
申請用カスタムオブジェクトのアクセス権の設計が必要 | 親オブジェクトと同じアクセス権を適用するのか、それとも申請用オブジェクト独自のアクセス権を適用するのか、運用に合わせた設計を検討する必要がある。なお、 mitoco の申請データオブジェクトは「非公開」で、承認者や回覧者にのみ自動で権限を付与するオプションが存在する。 |
おわりに
今回は、申請業務の改善・デジタル化、そして Salesforce のさらなる活用の手助けなればと思い、この記事をまとめてみました。
次回は、実際に試していただけるように具体的な設定方法を紹介したいと思います。
次回は、実際に試していただけるように具体的な設定方法を紹介したいと思います。
mitoco ワークフローに興味を持たれた方、もっと詳しく話を聞いてみたいという方は弊社までお問い合わせください。
37 件