事物形态提供一组特性，这些特性表示为在一组物理资产中共享的 属性、 服务、 事件和 订阅。事物形态最适合用来组合以描述模型中对象之间的关系。事物形态可以促进所包含的属性和业务逻辑的重用，且可以由一个或多个 事物模板来继承。在 ThingWorx 中，模型允许事物模板实现一个或多个事物形态，这类似于 C++ 中具有多重继承的类定义。如果已明确定义服务以允许其在父对象定义中进行覆盖，则可以从事物形态覆盖继承服务中的业务逻辑。

当对事物形态进行更改时，更改会传播到事物模板和实现该事物形态的 事物，从而可方便、快捷地维护模型。

如果有多个使用相同 ERP 系统的产品线，则事物形态的用例就是如此。例如，公司具有两个业务部门：一个负责制造家用割草机，另一个负责制造商用农业设备。割草机和农业设备没有通用的数据或行为。但是，它们都是可以跟踪的 ERP 资产。这两个部门都在同一个 CRM 系统中具有关于客户和服务票证系统的信息。要仅将这些接口作为物理资产实现一次，可以在事物形态中插入业务逻辑。例如，可实现一种将 ERP 系统中的相关数据转换为 ERP 连接器事物 (被表示为事物形态) 的方法。ERP 连接器事物可以拥有如下所述的配置数据：了解如何访问 ERP 系统 (例如，IP 地址)、如何对其进行身份验证 (例如，使用技术用户) 以及如何处理请求响应的配置数据。应使用 ERP 连接器事物中的服务来实现请求响应功能。然后，可以定义应用程序，以便从事物形态获取请求数据的特定功能。事物形态应具有表示为属性 (如“位置”和“ERP 资产 ID”) 的基本数据，以及获取资产特定数据 (如“获取我的未完成工作订单”、“获取我的工作订单历史记录”和“获取我的客户权利”) 的服务。然后，割草机和农业设备的事物模板可以继承事物形态的功能，且可以通过事物形态中封装的业务逻辑访问 ERP 数据。

使用扩展创建的事物形态与在 ThingWorx Composer 中创建的事物形态类似。它们是基本模板，用于创建属性、配置参数、服务等特性都相同的事物。在 Composer 中与在扩展框架内创建事物形态的区别在于：服务所使用的语言不同，服务的可见性不同。

Composer 模板：

Extension SDK 模板：