在与包括许多财富500强企业在内的客户讨论SharePoint时，一个共同的主题浮现出来：开发人员，无论是与外部客户合作还是内部团队，似乎都在推动沙箱解决方案，这出乎人们的意料。通常情况下，人们会期望IT专业人员和治理委员会从定制隔离的角度推动沙箱解决方案。沙箱解决方案的设计初衷是具有有限的SharePoint API子集，并且作用域限定在网站集合及以下级别。因此，与完全信任的解决方案相比，它在构建方面有很大的限制。
为什么选择沙箱解决方案？在SharePoint 2007 Online多租户农场中，ISV和客户对SharePoint 2007 Online的定制体验不满意，因为它只能通过SharePoint Designer 2007完成。SharePoint 2007 Online中没有完全信任解决方案的概念，SharePoint 2010 Online（在Office 365中可用）的多租户场景中也没有。沙箱解决方案是由微软构想出来的，纯粹是为了处理SharePoint 2010 Online部署带有托管代码和打包工件的定制能力。
尽管沙箱解决方案是为多租户场景设计的，但它们在本地部署也非常有用，因为它隔离了托管代码的执行，并智能地监控消耗的资源。如果资源消耗达到特定定义的限制，该网站集合中的所有沙箱解决方案都会被关闭。这是人们通常没有意识到的，他们认为只有违规的沙箱解决方案在网站集合中被关闭。这增加了显著的风险，因为一个网站集合可能有许多沙箱解决方案，整个网站集合的业务功能可能会因为一个违规的解决方案而受到影响。
进一步挖掘，发现开发人员想要使用这些而不是完全信任的解决方案的原因是，它不需要远程访问SharePoint服务器来部署它们。怎么做呢？拥有网站集合根网站完全控制权限或网站集合管理员成员资格，他们可以通过Web用户界面部署。
允许任何人在IT之外拥有这些提升的权限来部署沙箱解决方案的担忧是，它打破了典型的应用程序生命周期管理流程。本质上，它赋予了开发人员快速将更新的解决方案部署到环境中的能力。即使临终，也不会允许他们在生产环境中这样做！！！听说他们正在使用新的“敏捷”开发方法，这是必需的。完全不同意这种说法：当然，可以在开发环境中敏捷，但无论使用哪种方法来实施定制，都需要同样的严格程度。
应用程序生命周期管理流程确保对环境的任何更改都通过开发环境、集成环境和测试环境进行推广，在那里它们被质量保证，然后进入生产环境。在每个阶段，都有一个变更管理流程发生，以强制执行质量和确保生产环境中没有停机时间。当解决方案包更新时，需要进行重要的质量保证，因为现有的网站集合数据和任何发生的工件更改（例如，向现有内容类型添加网站列）需要进行测试。
实际上，如果他们拥有完全控制权或网站集合管理员，就不可能拒绝部署到解决方案库的能力，这实际上是一个具有权限的库，就像文档库一样。唯一真正的阻止沙箱解决方案的方法是完全关闭本地农场中的每个SharePoint服务器上的沙箱解决方案Windows服务，这在SharePoint 2010 Online中显然不可行。这是一种全有或全无的方法，大多数组织都不希望这样做。通常也不可能从用户那里拿走完全控制权或网站集合管理员权限，因为SharePoint的其他方面可能需要他们拥有该级别的权限。
沙箱解决方案的一个好处是，一些客户对此表示赞赏，当将其部署到网站集合中时，功能和工件仅在该处可用。与部署到Web应用程序的完全信任解决方案相比，该功能在所有网站集合中都可用。这通常不是一个可行的方法，因为解决方案可能只需要在农场中的一个位置，并且不应该对其他网站集合可用。