Thing Subscriptions
Subscriptions are services that receive and respond to events. A subscription has a source, usually a Thing. A Thing can have a subscription to an event that responds with an action. For example, if an entity fires a Motor is overheating event, it can subscribe to that event by triggering a Turn motor off subscription. Things can inherit subscriptions from the Thing Templates and Thing Shapes that they use.
A subscription is similar to a standard service, but it is explicitly linked to an event. This allows you to decouple the event from the code that responds to it. Like a service, you can implement custom business logic to react to the event. You can leverage the capabilities of the model by sending emails through a mail server Thing, writing to a database, or calling any services available in the platform. A subscription does not have an explicit return output like a service but can call any other service in the model to which the thread security context has access. The thread security context of a subscription is set to the same thread security context of the event that was fired. You can use the same JavaScript editing environment that is used to implement services.
Subscriptions have a defined input, which is the data packet issued by the event and referred to as event data. If the entity subscribes to a defined event, the event data is passed to the subscription function. The event data is described by the event Data Shape. Within the subscription implementation, the data that is passed from the event acts as the input to the script function. For example, if an entity is subscribed to a Thing property data change event, the subscription script function is called and the Thing property value, along with other relevant data from the event, is passed to the function as part of the event data.
Many entities can subscribe to the same event. Each entity receives a call to the subscription with the passed event data. An entity can take any action from the subscription script that it needs in order to achieve the solution requirements.
Some advantages of using this technique versus using a service that is called from another service are that an event can be subscribed to by one or many subscriptions, events are invoked based on system activity, and no user interaction is necessary. If an event should be subscribed to by more than one Thing, you can use a subscription instead of chaining multiple services.
* 
Multiple subscriptions to the same event defined on the same Thing, or duplicate subscriptions, are supported in ThingWorx version 8.4.0 and later.
Multiple Subscriptions
As of 8.4.0, subscriptions are named, which means they have a user-defined name that is a unique identifier. Entities can have multiple subscriptions to an event on a Thing. For example, if an entity fires a Motor is overheating event, it can subscribe to that event with both a Turn motor off subscription and a Create Work Order subscription to have maintenance look at the engine. Any number of other subscriptions can also be created for that event.
If a Thing Template or a Thing Shape implements a subscription to an event, the Things that use that Thing Template or Thing Shape can also create subscriptions to the same event and do not have to find other workarounds to take additional action when those events are fired.