Instances are described as being "associated" with a contact. This is because a given contact may have several instances associated with it. These instances can be of different Meeting Types or the same Meeting Type.
The following scenarios are both possible.
1. Two Instances each of a different meeting type, both associated with a single contact. These two instances can exist in both series & parallel.
2. Two Instances of the same meeting type, both associated with the a single contact. However these instance must only can be in an "Scheduling" state in series.
It's all about timing. Instances which are in a scheduling state, or in an impending final state (like an "Accepted" instance that has an end time tomorrow.) must only exist one at a time for a given meeting type. So instances of the same meeting type which are associated with the same contact must be activated in series. However, instances of different types and the same contact and free to exist in parallel.
This become more intuitive with an example: A single contact should not be able to receive 2 Demos at the same time because that would be confusing for the contact. However a contact should be able to receive a Demo and then after the End Time of that demo be able to receive another Demo. It also is reasonable for that a single contact to be able to receive an instance of Demo and another instance of a Support Session at the same time. As it is entirely possible that a single contact can be looking for sales to demo a new product, and support to help with an existing product in parallel.
Contact Fields
| First Name | Last Name | Company Name | Logic Field | Routing Field |
*Required
