结构化活动规定了一组活动发生的顺序。结构化活动通过将业务流程执行的基本活动整合到结构中来描述业务流程是如何被创建的，这些结构表达了业务协议中所涉及的控制模式、数据流、故障和外部事件的处理以及在流程实例之间进行消息交换的协调。
<sequence> 活动包含一个或多个顺序执行的活动。活动按照它们在 <sequence> 元素中出现的顺序被执行。当 <sequence> 中的最后一个活动已经完成的时候，<sequence> 活动本身就完成了。
<switch> 活动起的作用与许多传统编程语言中出现的 switch 构造很相似。switch 活动中有一个由 <case> 元素定义的、由一个或多个条件分支组成的有序列表，后面跟着一个可选的 <otherwise> 元素。每个 <case> 分支指定一个布尔 XPath 表达式，按照表达式出现的顺序对它们求值（条件表达式的求值所使用的逻辑，与前面讲述 <assign> 的部分所描述的用于一般表达式的逻辑几乎相同）。第一个布尔表达式值为真的 <case> 元素的子活动将获得执行。如果没有哪个 <case> 元素的条件为真，则执行 <otherwise> 元素的子活动。如果没有指定 <otherwise> 元素，则会有一个隐含的包含一个 <empty> 活动的 <otherwise>。当选定的分支完成时，<switch> 活动也就完成了。
<while> 活动重复执行它的子活动，直到对指定的布尔条件求得的值不再为真。条件被当作 XPath 表达式进行求值。
<pick> 活动包含一组事件处理程序。每个处理程序包含一个活动，处理程序在 pick 已经启动且处理程序正等待的事件发生时运行。处理程序包括警报处理程序，警报处理程序指定持续时间或截止期限，还包括消息处理程序（onMessage），消息处理程序等待来自某个特定伙伴、portType 和操作三元组的消息。消息处理程序能够按照与 receive 相同的方式创建一个流程实例，上面关于流程生命周期的部分描述了这种方式（使用 createInstance 属性）。只有第一个要接收它的事件的事件处理程序才会运行，一旦该处理程序的活动完成，<pick> 就将完成。
<scope> 活动为嵌套在其中的活动提供故障处理功能和补偿处理功能。在即将发表的关于故障处理和补偿的文章中将更详细地介绍作用域（scope）。
<flow> 构造提供了以并行方式运行活动的能力，还提供了定义防护性链接的能力。它可以包含任意数量的活动。当流被启动后，这个流中的所有活动就都做好了运行的准备，除非这些活动具有还没有求得值的传入的链接。流定义了一组链接，这些链接的源活动和目标活动都必须嵌套在这个流中。
<link>链接对于如何将流程的活动设置为运行施加了自己的约束。一旦一个活动完成了，它就对离它而去的链接上的任何条件进行求值。如果没有定义任何条件且活动已经正常完成，则所有条件的求值均为真。如果活动发生了故障，或者无法运行，那么活动向它所有的外发链接报错。另一方面，有传入链接的活动不得不等待，直到获得它所有链接传下来的值，方可运行。该活动还需要对它所包含的活动有控制权。例如，假设它是 sequence 中的第二个活动并且它的所有链接都已传入，如果该 sequence 中的第一个活动尚未完成，那么它也不会运行。一旦它拥有了这个控制权并且知道了它所有传入的链接的值，它就对一个被称为连结条件的条件求值。连结条件包含传入的链接的状态，如果活动要运行，则连结条件的求值必须为真。如果其求值为假，那么活动将发出一个连结失败的信号并且异常结束。如果该活动的隐式链接（来自父活动的控制权）为真且活动的各显式链接中有任意一个为真，那么缺省连结条件就为真。所有的链接条件均为 XPath 表达式。
