1
/
5

【あべ 開発Tips #4】Salesforceの組織統合について

Photo by Clay Banks on Unsplash

【サクッと読める:読了まで2分】

こんにちは!

代表の阿部です!

今日は、過去に私のXアカウントで、反響が多かった「Salesforceの組織統合」についてのポストについて、その際のフィードバックやコメントを交えて、語ろうと思います。

その時のポストがこちらです。


目次

  • Salesforceの組織統合についてのポストの背景

  • 組織統合の際の要所一覧

  • メタデータや、既存レコードの移行について

  • 両組織のオブジェクトの扱いについて

  • 組織のディスク使用料に注意

  • 何度も入念なリハーサルが大事

  • データローダーとAPI制限問題

  • 複数回に分けてデータ投入できるようにスケジュールを組む場合

  • データのマージは必要か?

  • AppExchangeの統合

  • その他の整理

  • 最後に


Salesforceの組織統合についてのポストの背景

このポストをした数日前に、社内Slackで、以下のような内容の相談があり、皆で意見を出し合いました。

「数か月後にSalesforceの組織統合が計画されている。設計から関わる事になるのだが知見が無い為、気を付けた方がいい点などを教えて欲しい」

そこで、あっという間にいろいろな知見が集まりました。

せっかくなので、同じような悩みを持つ方にも共有出来ればと思い、Xにもポストしたというのが、背景になります。

組織統合の際の要所一覧

まず、やりたいことを改めて。

2つのSalesforce組織を1つに統合するプロジェクトです。

個別案件の為、詳細は伺わずあくまでも一般的な要所について話合いを行いました。

以下が出てきた意見です。

メタデータや、既存レコードの移行について

オブジェクトの参照先レコードが無いと、レコード自体移行だけでなく、フロー、Apexのメタデータもすべてエラーになる為、参照先の一番親のレコードかデータ投入や、メタデータ移行を終わらせていく

両組織のオブジェクトの扱いについて

  • 両方の組織で特に標準オブジェクトの、運用や、入力制限、リレーションや、必須項目などは、整理が必要。組織間で同じオブジェクトの扱いが違う場合、まずはどのような扱いにするのか?を入念にチェックし、お客様とすり合わせを行わないといけない
  • 片方にしかない項目 => 新規作成の為、他への影響は軽微
  • 両方にある項目 => 用途や、処理での使用方法が同じかチェックする
  • 手元で移行先組織での、参照先の指定をする場合、Idで指定するが、旧組織のIdを項目として全レコードに持っておくと便利
  • Chatterのスレッドの移行は一括で出来ないはず

組織のディスク使用料に注意

2つの組織が統合されるので、単純にレコード数が倍増する。現在の契約のディスク使用量に空きがあるかどうか?を確認し、足りなくなりそうであれば、しかるべき対応が必要。

何度も入念なリハーサルが大事

1000万レコード単位以上の移行は相当な時間がかかる(一晩では投入が終わらない)為、FullSandboxなどで、入念なリハーサルを行い、掛かる時間、人数を図っておくと本番リリース時に大事故を防ぎやすい

データローダーとAPI制限問題

10万レコード単位での投入の場合、データローダーのBulk API設定一択にて作業を行う事になる。データローダーの処理は組織のAPIを使う為、API使用数が上限を超えてしまうと、APIを使った処理がすべてストップしてしまう。夜間作業になるかと思うが、その時間はバッチ処理が多い時間でもあるので、常に、現在と上限を確認して作業を行う。

複数回に分けてデータ投入できるようにスケジュールを組む場合

一定期間で、並行運用前提だったり、データ連携後に増えたデータの再投入す場合など、複数回データ投入する必要がある。何度もデータローダー投入用に成形する事も大変な手間なので、Data Spiderなど連携ツールの使用も検討した方がいい。

データのマージは必要か?

取引先や取引先責任者など、同じデータが存在する場合があり、メールアドレスや、電話番号などで重複レコードを統合する事も検討が必要。名寄せの条件も要検討

AppExchangeの統合

帳票などは、移管・設定作業だけで膨大になりやすい。この辺の整理と、工数への折り込みも大切

その他の整理

プロファイル、ロール、承認プロセス、ユーザーライセンス


その他、ステークホルダー(Salesforceの組織でいうと、従業員や、顧客、金融機関など)が大きく異なるので、業務プロセスと変更管理を標準化出来るかをまずは見るという意見もXにて頂戴しました。

以上が出てきた意見になります。これ以外にも個別の事案によって、整理した方がいい事はあるかとおもいますが、基準となる部分は上記でほとんど網羅できるのではないかと思います。


最後に

ということで、Salesforceの組織統合は、非常に難易度が高いですが、チャレンジしてみる機会があれば、ぜひチャレンジしてみてください。Salesforceのデータや処理、また業務プロセスに対する解像度が格段に上がります!

ではまた!


株式会社PROOF's job postings
2 Likes
2 Likes

Weekly ranking

Show other rankings
Like Yuji Abe's Story
Let Yuji Abe's company know you're interested in their content