Sitecore的工作流功能是许多大型组织依赖客户体验平台的原因之一。我们将了解如何响应特定于部门的工作流请求的请求：
拥有一个成功的网站不仅仅是一个伟大的设计和精心编写的内容; 当我们谈论一个由Sitecore驱动的时候，尤其如此。虽然使用企业内容管理系统的好处很多，但我们的许多客户都采用这种方式来实现各种工作流程，以便简化内容创建，发布和分发。让我们聊聊一些最常见的客户工作流程请求：
1.我们需要不同部门的不同工作流程
当我们开始与客户进行工作流程讨论时，我们经常听到一个共同的要求“我们需要不同部门的不同工作流程”。虽然评论准确反映了业务需求，但它并不一定直接转换为Sitecore中的实现路径。让我解释。
我们的客户实际承认的是，他们在组织中有不同的组（或内容作者集）负责网站不同部分的内容。这并不一定意味着需要多个Sitecore工作流程（稍后会详细介绍），但这确实意味着会话转向安全性，而不仅仅是工作流程。
Sitecore工作流程本质上非常简单。它充当内容门，确保内容不会在应该发布之前发布。如果将Sitecore工作流与安全性结合使用，您可以制定非常灵活的治理模型。
安全性可用于限制内容作者对内容的写入访问，同时还用于保护工作流状态和命令（命令允许用户将内容从一个工作流状态移动到另一个工作流状态）。最终结果是，您可以通过操纵内容权限或对工作流状态/命令的权限来控制内容作者编辑/创建内容的能力。
实际上，这意味着不同部门的用户可以使用完全相同的工作流程，只要他们的内容权限不同，因为Sitecore在确定是否允许用户写入内容时评估这两个权限。
2.我们不希望一个部门的内容作者看到另一个部门的工作流程项目
没问题; Sitecore让您满意。如果内容作者的权限组合不允许他们编辑项目，则该项目将永远不会显示在他们的工作流程中。实际上，安全性创建了一种隔离体验，每个部门只在工作流中看到他们的内容。
3.我们有内容作者为多个部门编辑内容
再说一遍，没问题。如果您使用显式授予权限而不是显式拒绝正确地推广您的安全性，那么您的所有角色和权限都将是附加的，这意味着您可以向内容作者添加多个部门角色。
我们想要一个特定部门的不同流程
没有汗水。Sitecore工作流程支持分支 - 您可以通过工作流程采用不同的路径。通过使用分支工作流，您可以使用单个工作流，同时通过批准流程支持不同的路径。同样，安全性用于确保只有具有适当权限的用户才能将内容发送到特定路径。这是通过保护用于将内容项发送到工作流中的下一状态的命令来实现的。内容作者只会看到他们被授予显式访问权限的命令。
5.分支工作流程和多个部门的用户有哪些注意事项？
在这种情况下要记住的一个重要事项是，您要在内容作者上负责选择正确的使用路径。作为多个部门成员的内容作者必须知道要使用哪个分支以及何时使用。这确实将可能的人为错误引入等式中，因为内容作者可以沿错误的路径发送内容项。
听完所有这些后，我仍然需要基于部门的工作流程。涉及什么？
基于部门的工作流程并不完全支持Sitecore的开箱即用。您可以创建多个工作流，但是，只能为模板分配一个工作流。要解决此限制，您可以复制（或通过模板继承）创建使用不同工作流的相同模板。你可以想象，这会很快变得混乱。
非线性的典型方法是编写自定义代码，通过使其更接近安全工作的方式来促进工作流分配：工作流应用于项级别，所有子项继承（以编程方式）相同的工作流（这是一个轻微的过度简化这篇文章的目的）。此方案的优点包括更清洁的项目基础和避免上述多模板方案。缺点包括您现在正在使用Sitecore的本机功能来使用自定义代码，从而引入可能的升级问题（尽管可能是小问题）。
7.我需要了解的有关工作流程的其他一些事项是什么？
让您的治理模型尽可能简单地开始。复杂的模型可能导致缺乏采用，并且从长远来看可能会产生维护开销。以下是我们始终与客户沟通的一些建议：
- 始终开始简单并随着时间的推移适应
- 使用Sitecore将预先批准的内容发布到网络上。如果您当前有内容审批的脱机流程，请不要期望该流程消失甚至更改。Sitecore不是用于版本/编辑审核更改的文档管理系统。
- Sitecore治理非常灵活，但灵活性带来了复杂性。应彻底测试工作流程和安全性。