当 ServiceModel 活动跟踪启用（ServiceModel 传播）或禁用（用户对用户活动跟踪）时，都会发生传播。
已启用 ServiceModel 活动跟踪
如果启用了 ServiceModel ActivityTracing，则 ProcessAction 活动之间会发生传播。
服务器
当属性 propagateActivity 同时设置为 true 客户端和服务器上时，服务器上的活动的 ID ProcessAction 与传播 ActivityId 的消息标头中的 ID 相同。
当消息中不存在 ActivityId 标头（即 propagateActivity=false 客户端上）或服务器上时 propagateActivity=false ，服务器将生成新的活动 ID。
客户
如果客户端是同步单线程的，客户端将忽略客户端或服务器的任何设置 propagateActivity 。 响应则改为在请求活动中处理。 如果客户端是异步或同步多线程，则在客户端中 propagateActivity=true，并且在服务器发送的消息中会有活动 ID 标头，客户端从消息中检索活动 ID，然后转移到包含传播的活动 ID 的“进程操作”活动。 否则，客户将从处理消息活动转移到新的处理动作活动。 这种额外转移到新的流程行动活动是为了保持一致性。 在此活动中，当为响应消息处理分配线程时，客户端将从本地线程上下文中检索 BeginCall 活动的活动 ID。 然后，客户端转移到初始“进程操作”活动。
如果客户端为双工，则客户端在接收消息时用作服务器。
错误消息中的传播
处理有效消息和错误消息没有区别。 如果 propagateActivity=true，添加到 SOAP 错误消息标头的活动 ID 与环境活动相同。
ServiceModel 活动跟踪已禁用
如果禁用 ServiceModel ActivityTracing，则直接在用户代码活动之间发生传播，而无需通过 ServiceModel 活动。 用户定义的活动 ID 也通过消息活动 ID 标头传播。
如果 ServiceModel 跟踪侦听器的 propagateActivity=true 并且 ActivityTracing=off（无论 ServiceModel 上是否启用了跟踪），客户端或服务器上将发生以下情况：
在发起操作请求或发送响应时，TLS中的活动ID会在用户代码之外传播，直到形成消息。 活动 ID 标头也会插入到消息中，然后再发送。
在接收请求或接收响应时，活动 ID 会在创建收到的消息对象后立即从消息标头中检索。 消息从作用域中一消失，TLS 中的活动 ID 就会进行传播，直至达到用户代码。
这些操作保证了在启用传播的情况下，用户跟踪将出现在相同的活动中。 但是，这不保证 ServiceModel 跟踪。 只有当这些跟踪的处理是在设置用户代码活动的同一线程上执行时，ServiceModel 跟踪才会出现在用户代码活动中。
通常，可以在以下位置观察到 ServiceModel 追踪：
如果禁用 ServiceModel 跟踪，则发出的所有跟踪都将出现在用户活动中。 如果服务器和客户端上都启用传播，则这些跟踪将在同一个活动中。
如果启用了 ServiceModel 跟踪，但禁用 ActivityTracing，则如果在两端启用了传播，则用户跟踪将显示在同一活动中。 ServiceModel 跟踪出现在默认的 0000 活动中，除非这些跟踪发生在与最初设置该活动的用户代码处理相同的线程中。
如果同时启用了 ServiceModel 跟踪和 ActivityTracing，则用户跟踪将显示在用户定义的活动中，ServiceModel 跟踪显示在 ServiceModel 定义的活动中。 在 ServiceModel 级别上发生传播。