我有两个组织，通过S2S共享联系人。
每个组织中的联系人具有相同的架构，它是标准字段和自定义字段。我只用两个自定义字段复制了一个基本案例：复选框字段A和数字（18,0）字段B.
Org 1发布字段A，并订阅字段B.
Org 2订阅字段A，并发布字段B.
Org 1通过S2S与Org 2共享联系人来启动所有S2S工作流程。组织2已自动接受。
组织2具有“插入前插入”触发器，其仅使用字段A来计算字段B的值。如果选中字段A，则将字段B填充为2，如果未选中，则填充为0.（这当然是对我真正需要做的过分简化，但它是基本可重复的情况。）
在Org 2中一切正常 - 联系人遇到字段A很好，我看到字段结果计算到字段B中。
问题是结果 - 字段B - 在下次联系更新之前不会自动共享回Org 1。它可以像我在Org 2中编辑同一个联系人上的非共享字段一样简单，例如“描述”，然后我立即看到先前计算的字段B的值被推回到组织1。
我假设这是因为，因为字段B的计算发生在Before Insert中，所以S2S连接假定当前更新事务仅由其自身执行（我可以看到这个逻辑如何有意义来防止无限的S2S更新循环）。
我首先尝试创建一个工作流字段更新，在字段B更改时强制更新（新的，虚拟的）共享字段，但仍然没有导致更新返回，可能是因为它与Salesforce认为的处于相同的执行环境中免于重新分享。还尝试了一个工作流规则，在更改字段时将Lead转发回连接队列，并且它也不起作用。
然后我在AfterUpdate触发器中尝试了重新更新语句 - 如果共享字段已更新，则重新加载并重新更新共享对象。这也行不通。
我确实找到了一个解决方案，它是AfterUpdate触发器调用的Future方法，它重新加载并触摸任何由BeforeUpdate触发器更改其共享字段的记录。这确实会导致现场结果在原始组织中以近乎实时的方式显示。
这个解决方案现在适用于我，但我觉得我必须遗漏一些东西。它导致执行更多的Future调用和DML，而不是必要的。
有没有人为此提供更优雅的解决方案？
答案 0 :(得分：1)
遇到了同样的问题，一位了不起的 Salesforce 支持代表发现了此文档，其中涵盖了 Salesforce 的具体指南：https://web.archive.org/web/20210603004222/https://help.salesforce.com/articleView?id=sf.business_network_workflows.htm&type=5
<块引用>有时使用 Apex 触发器而不是工作流是有意义的。假设您有一个工作流规则，在更新字段 A 时更新辅助字段字段 B。即使您的 Salesforce 到 Salesforce 合作伙伴订阅了字段 A 和 B，由您的工作流规则触发的对字段 B 的更新也不会发送到您合作伙伴的组织。这可以防止更新循环。
如果您希望将此类辅助字段更新发送到您的 Salesforce 至 Salesforce 合作伙伴，将工作流替换为使用提交后逻辑更新辅助字段的 Apex 触发器。
在双向连接中，Salesforce 到 Salesforce 的更新仅在“after”触发器（例如，“after insert”或“after update”）上触发，而不是在“before”触发器上触发。
这就是 OP 最终要做的事情，但是来自 Salesforce 的这份文档至少澄清了此处作为讨论的一部分所做的假设和猜测。它还有助于指出，在这些情况下使用“before”触发器以供将来参考并不是最佳做法。
答案 1 :(得分：0)
我认为没有更好的解决方法，那么你在做什么。未来标注的限制增加到相当高的水平，这不应该是您的关注。
可能是你可以做的其他事情（不确定这是否会起作用，因为我们仍然在同一个环境中） - 组织1 - 字段A已更新，发布合同
组织2 - 在Org 2中更新合同之前;如果已更新A - 在新自定义对象中保存合同的ID。 在更新新自定义对象后，更新给定合同ID的字段B. B的更新将发布