Types of specialty desk events

Note: Since the specialty desk service uses templates, we recommend you to review the basic specialty desk concepts first before you start working with the types of events it supports.

Spotnana APIs allow you to create the following types of Specialty Desk (SPD) events:

SPD trip
SPD session event

Specialty desk (SPD) trip

In a Specialty Desk (SPD) trip, the template parameters are inherited directly into the events and the standard trips created for each traveler. To edit, publish, or cancel the events in bulk all the eventIds must be used in the respective APIs. It is therefore recommended to store the eventIds in a temporary storage (e.g., a local storage, a database, or a browser session) so that they can be edited, published, or canceled.

This type is suitable for one-off events which don't require frequent edits. When creating a SPD trip, the type field must be set to PROGRAM_TRIP and the parentEventId must be set to the templateId. See the SPD trip creation workflow for step-by-step instructions on how to create a SPD trip.

Difference between a SPD trip and a standard trip

A Specialty Desk (SPD) trip refers to an event created from a template. In the API, these events must have the type field set to PROGRAM_TRIP. A standard trip refers to the travel itinerary created for the traveler who is invited to the event.

The SPD trip creation process involves:

Copying event details from a template.
Creating an event for each traveler using the template data.
Publishing the events.

Publishing the events will initiate the standard trip creation for travelers (one for each traveler). The traveler can use this standard trip information to learn about their itinerary for the upcoming event.

Fig: A representation of how a template, events, and standard trips are related in a SPD trip.

Note: See basic trip concepts to learn more about standard trips.

Specialty desk (SPD) session event

In a Specialty Desk (SPD) session event, the template parameters are initially copied into a parent event with a unique eventId. For every traveler added to the event, a child event is created for each and its event details are inherited from the parent event. In this event type the parent event acts as a container for all the child events. You can use the parent event’s eventId to access, edit, publish, or cancel all its child events.

This event type is suitable for events that have a large number of attendees (e.g., 200+ attendees) and when the events require frequent edits before and after publishing. When creating a SPD session event, the type field must be set to PROGRAM_SESSION and the parentEventId field must be set to the templateId. When creating child events, the type field must be set to PROGRAM_TRIP and the parentEventId field must be set to the eventId of the parent event.

See the specialty desk session event creation workflow for step-by-step instructions on how to create SPD session events.

Fig: A representation of how a template, events, and standard trips are related in a SPD session event.

Attached and detached child events

In a SPD session event, a child event is considered attached to its parent event if it has the same event parameters as the parent event. Otherwise, the child event is considered detached from its parent event.

For example, assume an event with 10 invited travelers. The event coordinator creates one parent event that inherits the event parameters from a template. He then creates 10 child events (one for each traveler) inheriting all the event parameters from the parent event. At this point, all 10 child events are attached to the parent event since they have identical event details. One of the travelers wants to book car services as part of the trip. So the event coordinator adds AIR and CAR as the allowedBookingingTypes for that traveler. Since, one of the event parameters is now different from the parent event, this child event is considered detached from its parent event.

This concept plays an important role when you’re bulk processing the events. For SPD session events, if you’re using the parent eventId in the request, any bulk editing only applies to attached child events. You can still use the same API to edit the detached child events separately by sending the respective child eventIds in the API request. Use the isDetached field in the get event API to know whether a child event is detached or attached to its parent event.

Difference between a SPD trip and a SPD session event

The table below explains the differences between a specialty desk trip and a specialty desk session event.

SPD Trip	SPD Session Event
The pre-configured event details are copied from a template directly into the events created for each traveler.	The pre-configured event details are initially copied from a template into a parent event. The child events created for each traveler will inherit the details from the parent event.
Common use case: Ideal for one-off event creations, where you just need to pre-fill from a template and publish the event without making any edits. Note: To be able to later access and edit these events, you must store all the `eventIds` in a temporary storage.	Common use case: Suitable for events that require grouping under a parent event so that they can be accessed and modified later.
The `type` field must be set to `PROGRAM_TRIP` in the create event API request.	The `type` field must be set to `PROGRAM_SESSION` for the parent event and `PROGRAM_TRIP` for all its child events.
When creating an event, the `parentEventId` field must inherit the value of the `templateId` of an event template.	When creating a parent event, the `parentEventId` field must inherit the value of the template’s `templateId`. When creating a child event, the `parentEventId` field must inherit the `eventId` of the parent event.
You should store the `eventIds` in a temporary session storage if you wish to modify the events later.	Since the parent event acts as a session storage, you can use its `eventId` to retrieve all its associated child events and bulk edit them.
A sample use case: A company is conducting an interview for an available position and must invite 3 eligible candidates. The event coordinator would create 3 events with `type: PROGRAM_TRIP`, inherit all the values from a template, specify the dates and times, and publish them. Note: To edit and publish these events, the `eventIds` need to be stored in a temporary storage (e.g., a browser session).	A sample use case: A company is conducting an annual offsite for 200 employees. Events like this will require frequent changes as the details are planned by the company. In this scenario, the event coordinator would create a parent event with `type: PROGRAM_SESSION`, inheriting all values from a template. For each of the 200 employees, a child event with `type: PROGRAM_TRIP` will be created, inheriting details from the parent event. Since these child events are linked to the parent event via the `parentEventId`, the coordinator can bulk edit all or just a subset of the 200 child events if they want to change the event details (e.g., event dates).

Note: See specialty desk workflows to learn about how SPD trips and SPD session events are created.