我正在尝试运行一个创建 1:n 关系的工作流。
我有一个 Contact 实体和 PortalRole 实体。当我将 PortalRole 与联系人关联时，我想触发一个向用户发送欢迎电子邮件的工作流。
PortalRoles 通过功能区按钮分配给联系人，该功能区按钮启动 HTML Web 资源并使用 JSON / JQuery 和 REST 服务来创建关联。
如何调用工作流？我需要获取联系人电子邮件地址并向他们发送 2 封电子邮件中的 1 封，具体取决于他们有多少关联（新门户用户或获得额外角色的门户用户）
【问题讨论】：
标签： workflow dynamics-crm relationship dynamics-crm-2011
您应该为 PortalRole 实体构建工作流并从 Create 触发它。您仍然可以访问工作流程中的联系人字段。
诀窍在于您的最后一个要求 - 为第一个角色关联发送“电子邮件 A”，然后为每个附加关联发送“电子邮件 B”。
您可以向联系人添加一个名为“分配的第一个角色”的是/否字段。您的工作流程将如下所示：
【讨论】：
这篇博文很好地解释了如何处理人际关系。
（这么多）多对多选项：使用哪个选项？
那么……在这三种方法中，哪种方法最好？与往常一样，这取决于 您需要做什么，但这里有一些经验法则可以用作 指导：
Native N:N
可能是最容易配置但限制最多的。当你使用 只需要知道两条记录是相互连接的，但是你 不需要有关连接本身的其他信息。
例子：
具有 N:N 到 Account 的自定义实体 Industry 添加自定义 N:N 要跟踪的竞争对手和地区实体之间的关系 哪些竞争对手在哪些地区活跃 自定义实体 颜色 带有 N:N 到联系人（您不会跟踪联系人的收藏夹 颜色？？？）
手动 N:N
需要多做一些配置工作，但通常值得付出努力。采用 当除了知道两条记录是相连的，你还需要 有关连接的信息，例如其状态，何时连接 创建等等。
例子：
协会和会员活动和注册（来自联系人的 1:N 到注册，从事件到注册的 1:N）订阅者和 订阅（从联系人到自定义实体“订阅”的 1:N，1:N 从自定义实体“订阅产品”到订阅）
连接和连接角色
正如我上面提到的，这些实际上是一个具体的实现 手动方法。如果你深入研究一下，你会发现 Connection 实体是一个真正的可定制实体。你可以 甚至自定义它，将自定义字段添加到连接表单等 向前。但是......小心过度：只有一个连接 实体，并且为一个连接角色进行的自定义通常会 不适用于另一个。
其中一个特定的优点是单个连接角色可以 连接不同类型的记录（例如，联系人可以参考其他 联系人、客户和机会）
这是一个判断电话，但我会说在您需要时使用这些 跟踪有关实际连接的一些信息（例如何时 它们被创建了，有多少......），但不是那么多。例子：
推荐（联系人到联系人、联系人到客户、联系人到 机会）前雇员（联系客户，领导客户） 董事会（联系自定义实体“董事会”，领导董事会）
【讨论】：