Orgの解き方

シナリオを読み、以下のようにSalesforceの組織構成について、単独(1Org・シングルオルグ・単独環境)でいくか、マルチオルグでいくか選択し、なぜそれを選択したか根拠を示す必要があります。

稀にマルチオルグが回答になるケースがあると思いますが、例えば権限など規制要件やあまりにもデータ量が多すぎてガバナ制限を考慮すると組織を分けざるを得ないケースが該当します。分け方としては、地域やビジネスユニット単位が多いです。

以下、Orgを判断・検討するための判断軸の例です。

＜機能＞

・レポートやChatter、レコードの共有機能というのは組織単位で使える機能となります。（他SalesforceOrgのデータを、標準レポートで参照することはできませんよね。）
ですので、1OrgであればレポートやChatterなどコラボレーション機能を活用できる点や、レコードの共有など組織内で行える点がメリットとなります。
　→一方裏を返すと、マルチOrgにしてしまった場合、組織を跨いで上記機能が使えないので、そこがデメリットとなります。
・よくあるのが複数の国が利用しており、各言語に応じてシステム上のラベルを切り替えたい・通貨を切り替えたい要件がありますが、トランスレーションワークベンチやマルチ通貨で対処ができますので、その要件ではマルチオルグにする判断基準にはなりえません。（左記機能を利用する場合、何か制約はあるか？を突っ込まれるケースもあります。使う機能はすべてメリデメや根拠を聞かれる可能性があると考えたほうがいいです。（例：マルチ通貨は一度有効化すると無効化できないので、Sandboxで影響確認してから有効化を決めるべきである、など。））

＜LDV/ガバナ＞

大量データを扱う場合はガバナ制約に抵触する可能性が高まります。（組織単位でガバナ制約の上限が定義されているためです。https://developer.salesforce.com/docs/atlas.ja-jp.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm）
例えば、インターフェースだとAPIコール数（SalesforceのAPIを叩ける回数制限）であったり、検索だとデータのクエリで5万件までしか取得できないなどです。組織単位で存在する制限ですので、組織が分かれるとデータ量が分散され、当然ガバナ制限に抵触しづらくなる・扱うデータも少なくなります。
→ですので、1組織でアーカイブなどしても対処できないような大量データを扱う場合や規制要件で同じ組織にできない場合、マルチOrgになり得ます。

＜連携・認証＞

1Orgの場合に、連携や認証がシンプルになります。
逆に複数のSalesforce組織がある場合、想像してほしいのですが、顧客マスタの持ち方や、ナレッジのような一元管理したいマスタの持ち方、認証マスタの持ち方など、考慮事項・検討が増えるに加えて、認証設定や共通資材の構築などそれぞれの組織にて行うので、開発やテストも当然増えていきます。
また、システム連携についてもミドルウェアでルーティングやフォーマット変換が発生し、複雑な仕様となります。仕様変更の際にも複数組織に影響調査や開発・テストが必要になるケースがあります。キーの持ち方も考慮が必要でしょう。

＜サポート管理工数＞

仮にSalesforce組織が複数になった場合に、コールセンターの管理工数が増えるように思います。（コールセンターの定義の単位にもよりますが、組織ごとに画面や機能、マニュアルなど必要になります。）
操作／管理するシステムが二重になるケースもありますし問い合わせがシステムによって分かれるので、うまくサポート担当に業務割り当てるなど、なかなか管理する側も難しいかと思います。
→ですので、1Orgであればこういったサポート管理工数が低減になる点もメリットです。

＜デプロイ工数＞

古いCRMなどを廃止し、Salesforceに移管するシナリオが多いのですが、その際にレコードタイプやパスなど使い、プロセスやレイアウトの標準化を行うかと思います。（せっかく新しいシステムにするなら、汎用的でメンテナンスしやすい作りにしたいですよね。汎用的にすればワークフローのステータスをレポートで一元管理できたり、保守しやすいなどメリットがあると思います。ですので、古いCRMシステムが複数あって、それぞれ個別にプロセス定義していたとしても、Salesforce移管タイミングで標準化できるところは標準化していきたいものです。）
標準化する前提において、組織がわかれてしまうと、重複資材が増えてしまい、テスト工数やデプロイ工数など組織ごとに二重で発生してしまうケースがあります。これがマルチOrgのデメリットにあたると考えます。
※ちなみに古いCRMがSalesforceだったりするケースもあるので、ここは試験前に色々なパターンのシミュレーションをしておいたほうがいいです。

＜規制要件＞

規制要件により、明確に同一組織に他国のデータを持ってはならないなどシナリオに書かれていた場合、組織を分けざるを得ません。マルチOrgとなります。

上記以外にも軸があると思いますが、とにかく時間のない試験で、あまり時間をかける箇所じゃないと思いますので、プレゼンの際にはさらっと1分くらいで結論と根拠を話せるようにしておく必要があります。
また、もしQAで突っ込まれた時には、背景を即座に話せないといけません。

また、単純に新システムにおいて１Orgかマルチか問われるケースと、既存ですでにOrgがいて、それを統合するか否か問われるケースがあります。既存がSalesforceであるケースもあるかもしれません。
（個人的には、既存はだいたいパイロットだったり複雑に拡張性なく作られている前提が多いと思いますので、標準化などのメリットを伝えて、新システムに移行するケースが多いです。既存はｈ）

★参考になるURL
▽Salesforceの組織戦略（Org Strategy）について考える
https://base.terrasky.co.jp/articles/STo3R

▽いまいちだけど、関連資料
https://qiita.com/nori83/items/921d3f1d56b84b4afe6c