何時將系統分成多個Dynamics CRM實例

Question

我的組織剛剛開始涉足Dynamics CRM，其中一個問題是我們應該何時將各種應用程序組合到一個實例中，以及何時應將它們分離爲多個實例？

我知道這個問題的答案取決於具體情況，所以我想拿出的，可以被要求幫助確定哪個方向是最有意義的問題清單。

我在網上找到任何有關這方面的討論令人驚訝的困難時間，所以我想在這裏問一下。那麼，在決定系統/功能集是否應該在單獨的實例中時，您會問什麼問題？

編輯： 我不是很清楚我們的組織類型。我爲一個擁有多個部門的城市工作，這些部門提供不同的服務，併爲不同的客戶提供所需的不同功能。

我很擔心所有這些具有不同功能的不同系統，並將不同的「客戶」跟蹤到一個系統中。我擔心，管理適用於不同系統的所有各種實體並確保來自一組用戶的更改請求不會導致不同組用戶出現問題的問題將會出現。

我敢肯定，有時它會是有意義的多系統組合成一個實例，但我覺得有可能只是因爲很多次，我們不想把它們放在一起，所以我想拿出一個要問的問題列表。

一些基本的人將是： 1）DO系統共享公共數據（例如，同一客戶）？ 2）系統是否共享通用功能？ 3）系統是否收集相同類型的數據？ 4）是否需要報告這些系統的組合數據？ 5）通過分離實例或通過用戶角色來管理安全性會更容易嗎？

Answer 1

根據我的經驗，單個實例是常態。我認爲單個實例的好處非常重要。

你可能要考慮的幾點：

• 你想在孤島的數據？如果是這樣，多實例提供了一個非常簡單的方法來實現這一點。但是具有適當安全模型的單個實例也可以實現此目的。
• 您是否希望跨應用程序將數據合併到單個業務流程中？如果是這樣，多實例意味着你必須在實例之間建立一個集成。單實例沒有這個問題。
• 是否要在每個實例中使用自定義構建的功能？如果是這樣，一個實例就直接提供了這個。多實例需要單獨開發和部署到每個可能增加成本的實例。
• 你考慮過授權嗎？我不是授權專家，但我相信如果您在線多實例將會吸引更高的授權費用。

作爲一個經驗法則，我會說單個實例是默認位置，因爲它允許您輕鬆地組合數據和過程。如果你想去多實例只是有一個很好的理由，並確保它不是一個可以由單個實例提供的東西。