Salesforce承認プロセスをkickflowに置き換えてみた
はじめに
SHIFTにおけるSalesforceを中心としたベスト・オブ・ブリード推進の一環で、会社の成長に耐えられなくなった承認プロセスのkickflow置き換えを実際にやってみました。
「ベスト・オブ・ブリードってなんだ？」についてはこちらを参照⇒ Salesforceを中心としたベスト・オブ・ブリードの推進
この記事では、実際に置き換えた際に発生した問題点や対処法について紹介していきます。
Salesforceの承認機能をkickflowに置き換えたことで、標準の承認プロセスでは実現できなかった柔軟な承認者や経路設定が可能になり、運用が効率化されました。
しかしながら、運用開始後は開発中には想定していなかった問題も発生しました。
Salesforceと別のシステムを連携する際に起こり得る問題としてよく見られるものと思われます。この記事が参考になれば幸いです！
実現イメージ
申請者/承認者のオペレーションをほとんど変化させないシステム構成および処理フローとしました。
例:
申請者は今まで通りSalesforceの「承認申請」ボタンから申請
承認者はkickflowチケットでSalesforceの情報が参照可能
システム構成
システム構成は以下のようになっています。
Salesforce：申請者が承認申請を行うシステム
PowerAutomate：承認申請をトリガーとしkickflowチケットを作成する/kickflowチケット承認をトリガーとしSalesforceレコードを更新するシステム
kickflow：承認者が承認を行うシステム
処理フロー
処理実行
Salesforceで承認申請を実行すると、レコードにロックがかかり、PowerAutomateフローのトリガー項目が更新される。
チケット作成
kickflowチケット作成フローが起動する。kickflowチケットが作成され、そのチケット情報（URLなど）はSalesforceレコードに同期される。
チケット承認
承認者はチケットを承認する。最終承認されると、チケットが完了状態になる。
チケット結果反映
PowerAutomateのチケット完了時フローが起動し、Salesforceのレコードが更新される。
処理完了
レコード更新後、Salesforce内のフローにてレコードのロックを解除する。
運用開始後に発生した問題
大きく分けて4つの問題が発生しました。
Salesforce側の処理制限によりエラーになる
Salesforceのレコードが古いことによりエラーになる
Salesforceの処理順によりエラーになる/誤った値で更新される
kickflowチケットが二重で作成される
（問題が発生した箇所を×印で表します）
1.Salesforce側の処理制限によりエラーになる
同時に行われる申請があまりにも多く、多数のフローが同時に起動⇒多数のSalesforceレコードを同時に更新しようとしてSalesforce側でエラーになってしまいました。
これは起こりうるだろうと予測して事前準備も行っていたのですが…実際に運用するとやはり発生してしまいました。
2.Salesforceのレコードが古いことによりエラーになる
Salesforceでは、過去レコードを更新する際、今の入力規則や選択リストなどの制限に引っかかりエラーになってしまうことがあります。
承認申請されたレコードが過去のものの場合、チケット結果反映のときにエラーが発生することがありました。
一部のパターンは想定していましたが…「古い状態だとエラーになる」項目すべてを洗い出せていませんでした。
3.Salesforceの処理順によりエラーになる/誤った値で更新される
Salesforceレコード更新後、Salesforce側で後続の処理が動きますが、機能によって処理の順番は決まっています。
PowerAutomateフローでレコード更新することで処理順が微妙に変わり、エラーを引き起こしたり項目が誤った値で更新されてしまいました。
エラーはリリース後すぐに気づき修正しましたが、誤った値はユーザからの問い合わせがあるまで気づきませんでした。
4.kickflowチケットが二重で作成される
承認申請後、PowerAutomateフローがトリガーされkickflowチケットが作成されるまでにラグがあります。
この間に当該レコードが再度編集されると、PowerAutomateフローのトリガー条件を再び満たし、チケットが二重に作成されてしまいます。
当該レコードにはロックをかけているのですが…裏から更新される可能性を見落としてしまいました。
緊急暫定対処とその効果
発生した問題は、以下4つの方法で暫定対処しています。
①PowerAutomateの処理を修正
②Salesforceの処理を修正
③管理者向けエラーメッセージ改修（管理者で手動対処）
④ユーザ向けエラーメッセージ改修（ユーザで手動対処）
1.Salesforce側の処理制限によりエラーになる、の暫定対処
対処方法：①PowerAutomateの処理を修正 ⇒ ③管理者向けエラーメッセージ改修
フローを直列実行する「コンカレンシー制御」で、Salesforceレコードの同時更新を回避しました。
結果、レコード更新の競合はなくなったものの、今度は直列処理のキュー数制限に引っかかったため、管理者が手動対処しています。エラーメッセージから処理を再実行できるようにしました。
発生頻度は高くないので、現時点ではこれで十分です。
※発生頻度は「並列処理の競合 ＞ 直列処理のキュー数制限オーバー」です。
** 補足：コンカレンシー制御でユーザの業務が止まらないか？**
今のところは問題なく運用できています。「大量の申請を1つずつチェックし時間がかかる ⇒ その間に次のチケットが作成される」ため、業務が止まることはありません。
2.Salesforceのレコードが古いことによりエラーになる、の暫定対処
対処方法：④ユーザ向けエラーメッセージ改修
ユーザ向けエラーメールに、考えられる原因パターンの記載を増やす
エラーメッセージをSalesforceレコードの項目に記載する
結果、このエラーによる問い合わせはほとんどなくなりました。
3.Salesforceの処理順によりエラーになる/誤った値で更新される、の暫定対処
対処方法：②Salesforceの処理を修正
こちらは調査の結果PowerAutomateの問題ではなかったので、Salesforce側の処理を修正しました。
結果、今のところ新たな問題は発生していません。
4.Pkickflowチケットが二重で作成される、の暫定対処
対処方法：①PowerAutomateの処理を修正
こちらもコンカレンシー制御で対処しました。PowerAutomateフロー処理中にトリガー条件となる項目を更新し、二重でトリガーされないようにしました。
こちらの効果は現在確認中ですが、しばらく同様のエラーが発生しなければOKとしたいと思います。
今後の課題
一旦、今回は「暫定対処」でOKとしたので、次回以降同様の不具合を発生させないための仕組みを作る必要があります。
テストケースを充実させることで事前に洗い出せる不具合の数を多くしていきます。
正常系テスト
⇒改修が直接的に行われた処理だけでなく、後続の処理もテストケースに含める
異常系テスト
⇒エラー時のテストケースが少なかったので、ユーザが対処できるかどうかの観点でケースを増やす
負荷テスト
⇒10件同時処理で不具合を検知できなかったので、20件の処理を同時に行う
まとめ
承認機能をkickflowに置き換えたことにより、まずは課題であった「SHIFTの成長に耐えられる必要がある」ものは手に入れられました。
発生した問題は、事前に想定して対処できたものもありますが、やってみないと分からなかったものも結構ありました。暫定対応を素早く行えたので、今回はひとまず成功としたいと思います。
今回の改修のおかげで、どのような点を重点的に想定しておくべきかが分かりました。システム間連携を行う際には必ず想定しておかなければならないことなので、（自分自身も含め）同様の取り組みを行う方への参考になればうれしいです！
執筆者プロフィール：はる
コーポレートプラットフォーム部の賑やかし要員。
Salesforce歴6年。SIerでSalesforceを3年経験後、さまざな案件を経てSHIFTでもSalesforceなどを担当し、SHIFTの案件拡大を支えている（ハズ）
第1回SHIFT麻雀王決定戦準優勝。
好きな食べ物はハンバーガー。
お問合せはお気軽に
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
PHOTO：UnsplashのGalina Nelyubova