Overview

Removes selected ticketing requests from the current processing instance.

How it works

The Delete ticketing request step removes ticketing requests previously assigned to the current processing instance.

Use this step to cancel ticketing requests that are no longer applicable. Removing a ticketing request causes the Ticketing request exist condition to evaluate as false. This prevents the current processing instance from being routed to workflow paths that depend on this condition, unless another ticketing request is assigned later.

Although there is only one ticketing request marker, it can be assigned from different sources. This step allows you to remove ticketing requests created by selected sources only.

Settings

Specifies which ticketing request sources to remove.

Multiple sources can be selected:

• Manual – Removes ticketing requests assigned manually from the Monitoring Panel.
• Evaluation threshold – Removes ticketing requests assigned automatically by the Start step when a Fare increase rule with the Issue tickets option enabled is triggered.
• Scheme action – Removes ticketing requests assigned automatically by any other workflow components.

Overview

Used to exchange data between Trava and external web applications via HTTP.

Description

The HTTP Notification step enables integration between Trava and external web applications by sending HTTP requests during scheme execution.

It allows you to send custom requests containing dynamic data from the processed PNR or ticket and optionally retrieve data from the HTTP response for use in subsequent workflow components.

The step sends an HTTP request using the configured method (POST, PUT, or PATCH) to the specified endpoint.

The request payload can consist of:

• custom text or JSON;
• one or more system variables;
• or a combination of both.

System variables are automatically populated with values from the processed PNR or ticket.

If configured, the response returned by the server can be parsed and stored in custom variables. These variables can then be used by subsequent workflow components, such as conditions, remarks, or additional HTTP Notification steps.

Settings

1. Use template

   Applies a pre-saved configuration instead of manual setup. Useful when multiple schemes use HTTP Notification components with identical configurations.

   ℹ️

   Tip

   Changing a shared template automatically updates all components using that template. For details on managing templates, see the Templates section.
   ⚠️

   Warning

   Applying a template overwrites any settings entered manually in this step.

2. Endpoint url

   Specifies the destination URL.

   Supports:

   • full path to an external HTTP/HTTPS resource, including the protocol (for example, https://);
   • relative path when using the Trava API.

3. Authentication method

   Specifies the authentication method used when sending the HTTP request.

   Supports:

   • Anonymous – no authentication.
   • Basic authentication – uses a user name and password.
   • Bearer token – uses a token obtained from an external service.

   Selecting Basic authentication or Bearer token displays the corresponding additional fields.

   ⚠️

   Warning

   The selected authentication method and provided credentials must match the requirements of the receiving API.

4. Message

   Specifies the content of the message to be sent.

   Supports:

   • plain text, or
   • structured data (for example, JSON).

   Can include custom variables to personalize the message content.

5. Variables

   Selects one or more variables whose values are sent to the external application.

   If at least one variable is selected, the system automatically generates the HTTP request body as JSON, where each variable name is used as a key and the value is populated from the processed PNR.

   ℹ️

   Tip

   If Message is also filled in, its content is added to the generated JSON under the notificationMessage property.

6. HTTP custom headers

   Allows adding custom HTTP headers to be sent with the request.

7. HTTP method

   Specifies the HTTP method used to send the request.

   Supports:

   • POST (default);
   • PUT;
   • PATCH.

8. Send as plain text

   Specifies the format of the data sent in the HTTP request body.

   • If enabled, the data is sent as plain text.
   • If disabled, the data is sent in JSON format.
   ℹ️

   Tip

   When custom variables are used in plain text mode, only the value of one variable is sent.

9. Number of notification attempts for erroneous responses

   Specifies the maximum number of retry attempts before the system stops trying and raises an error.

10. Save response to custom variables

    Allows capturing the server's response and storing a value from it in a custom variable. The stored value can be used as input for subsequent components or conditions in the workflow.

11. Preview

    Allows testing the payload before scheme activation. Enter a specific PNR or select one from the list to view the exact JSON payload the system generates for that PNR.

Examples

Example 1

Sending a custom JSON message to an external web application (Postman) using a POST request.

Configured options:

1. Endpoint URL: https://postman-echo.com/post
2. Message: {"sample_payload": "test"}

Payload:

{"sample_payload": "test"}

Response:

{
  "args": {},
  "data": {
    "samplePayload": "test"
  },
  "files": {},
  "form": {},
  "headers": {
    "host": "postman-echo.com",
    "contentLength": "26",
    "accept": "application/json",
    "contentType": "application/json",
    "traceparent": "00-a00bfb6096f35ea86ff902f0dd985ad9-e2cbcfb037f52ef6-01",
    "acceptEncoding": "gzip, br",
    "xForwardedProto": "https"
  },
  "json": {
    "samplePayload": "test"
  },
  "url": "https://postman-echo.com/post"
}

Example 2

Sending JSON message with the values of the selected variables to an external web application (Postman) using POST request.

Configured options:

1. Endpoint URL: https://postman-echo.com/post
2. Selected variables

Payload:

{
  "PNR": "HZJDOV",
  "issuingCarriersCodes": ["AY"],
  "destinationCityCode": "OSA"
}

Response:

{
  "args": {},
  "data": {
    "PNR": "HZJDOV",
    "issuingCarriersCodes": ["AY"],
    "destinationCityCode": "OSA"
  },
  "files": {},
  "form": {},
  "headers": {
    "host": "postman-echo.com",
    "contentLength": "153",
    "accept": "application/json",
    "contentType": "application/json",
    "traceparent": "00-af825e9bcd629cf2c3a1cc705f9111cc-8fd8fed62f3871e1-01",
    "acceptEncoding": "gzip, br",
    "xForwardedProto": "https"
  },
  "json": {
    "notificationMessage": "{\"my_parameter\": \"value\"}",
    "pNR": "HZJDOV",
    "issuingCarriersCodes": ["AY"],
    "destinationCityCode": "OSA"
  },
  "url": "https://postman-echo.com/post"
}

Example 3

Sending a message together with variables.

In this scenario, the component is used to send a JSON consisting of the value of the Message field and the values of the selected variables to an external web application using a POST request.

Payload:

{
  "NotificationMessage": "{\"my_parameter\": \"value\"}",
  "PNR": "WYDYES",
  "IssuingCarriersCodes": ["AI"],
  "DestinationCityCode": "KTM"
}

Response:

{
  "args": {},
  "data": {
    "notificationMessage": "{\"my_parameter\": \"value\"}",
    "pNR": "HZJDOV",
    "issuingCarriersCodes": ["AY"],
    "destinationCityCode": "OSA"
  },
  "files": {},
  "form": {},
  "headers": {
    "host": "postman-echo.com",
    "contentLength": "153",
    "accept": "application/json",
    "contentType": "application/json",
    "traceparent": "00-af825e9bcd629cf2c3a1cc705f9111cc-8fd8fed62f3871e1-01",
    "acceptEncoding": "gzip, br",
    "xForwardedProto": "https"
  },
  "json": {
    "notificationMessage": "{\"my_parameter\": \"value\"}",
    "pNR": "HZJDOV",
    "issuingCarriersCodes": ["AY"],
    "destinationCityCode": "OSA"
  },
  "url": "https://postman-echo.com/post"
}

Notes

Troubleshooting

If an issue occurs with the HTTP Notification component, take the following steps before submitting a bug report:

1. Review the processing session log. Errors sending a request appear in the log with the status, response message, response content, endpoint URL, and variables used.
2. Verify the error source. Server errors such as 500, 503, or 404 indicate a problem with the external application, not with Trava.
3. Confirm the outgoing request. If the request is formatted correctly and includes all required values, the request left the system as intended. Investigate the issue in the receiving service or your own infrastructure.

Overview

Redirects a PNR, ticket, or EMD to be processed by another scheme.

How it works

The Process by another scheme step links processing of an object across multiple schemes. The system passes the object to the selected scheme and starts its processing, either by creating a new instance or resuming an existing one. The timing of the launch and the resume behavior are controlled by the step's settings.

Settings

1. Select object to process

Defines the object to process in another scheme:

• PNRs or Related PNRs – for schemes that process bookings.
• Tickets – for ticketing schemes.
• EMD – for schemes that process EMDs.

2. Select destination scheme

Defines the scheme or schemes to which the object is passed for processing. Available schemes appear in a drop-down list.

3. Start processing immediately

Allows resuming processing in the destination scheme without waiting for the scheduled time, when the instance status is Paused.

If disabled, the destination scheme does not intervene and processing runs on schedule. In this case, the processing history logs the following warning:

Instance for processing [Object ID] under schema "Schema name" already exists but could not be started.
Reason: The next processing time is already scheduled and there is no requirement for an immediate processing start.

4. Restart completed processing

Allows restarting processing in the destination scheme for objects that already completed processing there and currently have the status Completed.

If disabled, an incoming object with the status Completed is not restarted. The processing history logs the following record:

Instance for processing [Object ID] under schema "Schema name" already exists but could not be started.
Reason: Processing has already completed and there is no requirement to restart.

5. Delay before start

Defines the delay before the destination scheme starts processing, allowing the current scheme to finish processing. Default value: 15 seconds.

Notes

Often used with

• The active instance is processed in a different schema (condition) – checks whether the PNR has already been processed by another scheme.
• Stop processing by another scheme (action) – stops processing in one or several schemes.

Overview

Removes selected tags from the target level, or removes all tags at once.

How it works

The system removes all tags or only the tags specified in the step settings.

The step settings determine where the tag is removed — at the instance level or at the object level.

• A tag removed at the instance level is removed only within that instance.
• A tag removed at the object level (PNR, TKT, or EMD) is removed from the object entirely. Neither the current scheme nor other processing will detect the tag until it is set again.

ℹ Note: The set of available objects depends on the scheme type.

Settings

[image]

1. Title

Specifies the name of the element as it appears on the workflow canvas. Defaults to "Remove tags". The value can be edited manually.

2. Select the tag removal target level

Selects the target level for tag removal — at the instance level or at the object level (Tag's target level [object]). Available objects depend on the scheme type.

For PNR Processing, PNR Pricing, and PNR Redirector schemes:

• Instance – removes tags from the current instance.
• PNR – removes the tag from the PNR.
• Ticket – removes the tag from the ticket.
• EMD – removes the tag from all EMDs linked to the ticket.

For Ticket Processing and EMD Processing schemes:

• Instance (for the ticket or EMD, respectively) – removes the tag from the current instance.
• Ticket / EMD (respectively) – removes the tag from the object itself.

3. Restrict removal to documents by condition (document level only, for PNR Processing scheme types)

Opens a searchable list of conditions (Add ticket condition). One or more conditions can be selected.

💡 When conditions are selected, the document tag is removed only from documents that match them.

4. Remove all tags at once

Allows removing all tags from the target level instead of selecting them individually (Remove all tags).

💡 When this checkbox is enabled, the tag list below is not displayed — all tags are removed regardless of selection.

5. Select tags to remove

Displays the tags available for removal. The list depends on the target level set in setting 2 and the selected scheme type.

• clear selection – deselects all selected tags.

Overview

Sends an email to the recipient address specified in the settings.

How it works

The system determines the recipient email addresses. It builds the email based on the settings configured on this step, then sends the email to the recipients.

Recipients can be entered manually, extracted from the corresponding PNR fields, or taken from the Agents setting under Offices (Offices → Agent).

The email body can use a previously created template or an individual template configured directly on this step. Variables allow the system to pull data from the PNR or from the system to generate personalized emails for each recipient.

The email text supports multiple languages.

💡 Use the variables defined in System Settings → E-mail Branding to apply, depending on the PNR's creating or owning office, or on remarks present in the PNR.

Settings

[image]

1. Title

Defines the name of the element displayed on the workflow canvas. The default value is Send e-mail. This value can be changed manually.

2. Use e-mail template

Allows the step to use a previously created email template instead of an individual configuration on this step. Useful when multiple workflows and schemes use identical configurations.

💡 Editing the template updates it immediately on every step where it is used.

💡 When a template is applied, all settings entered manually on this step are overwritten.

3. Configure recipient addresses

Select how the address is determined for the To field from the drop-down list:

• Send to email – the address is entered manually in the text field.
• Send to client (PE only) – the address is extracted from the email field in the PNR contact details.
• Send to client (PE or SSR) – the address is extracted from the email field in the PNR contact details. If the field is missing, the system uses the fallback address defined in SSR CTCE.
• Send to agent – the address is determined by the Agents setting of the office (PCC) that the processed PNR belongs to.

💡 For Send to agent, specify a fallback address in the Fall back field in case the agent's address cannot be determined.

Enter addresses for CC and BCC manually.

The {} button next to each field inserts a variable value.

4. Specify email importance

Select the importance level of the email from the Importance drop-down list: Low, Normal, or High.

The default value is Low.

5. Time zone for time variables

Select a time zone in the Time zone for time variables field. The value determines the time zone used for all date- and time-related variables generated by the system.

By default, the system uses the time zone linked to the client's Trava system (backoffice).

6. Sender's name

Enter the sender's name in the Sender's name field. The field supports free text or a variable value.

7. Sender's email address

Enter the sender's email address, or select a variable value using the {} button.

By default, the field is automatically populated with the address specified in the Error e-mail field of the Scheme properties settings.

💡 The sender's address is used correctly only if it matches and is permitted for the domain specified in System Settings → SMTP server.

8. Add language

Add one or more languages for the email. The list of available languages is based on the value of the Comma-separated list of cultures for using on the site parameter in the system settings (Global → General).

Adding at least one language is required.

If multiple languages are added, the system selects the language to apply based on a remark added to the PNR. The remark-to-language matching rules are configured in System Settings → GDS Common → Culture and Language Detection Rules → Remark content analysis to detect passenger locale and language.

💡 Once the system determines the locale for a PNR, it continues to use that locale afterward, even if the remark is later removed.

9. Subject

(available after selecting a language in setting 8)

Enter the email subject in the Subject field. The value is set separately for each added language.

10. Preview

(available after selecting a language in setting 8)

Enter a PNR number in the Preview field to preview the email template. Allows checking how the email will appear to the recipient before saving the step settings.

11. E-mail body

Edit the email content for the selected language using the built-in editor. The value is set separately for each added language.

The editor consists of two panels:

• A text formatting toolbar — standard editing functions (font, style, lists, tables, images, links, and so on), including AI assistant and Source. [TO CONFIRM: purpose and functionality of AI assistant]
• A variable panel grouped into categories: System, PNR, Processor, URLs, Backoffice, Agent, Brand, Custom. Each variable name reflects its content. Hover over a variable to see its description in a tooltip.

Source switches the editor to HTML editing mode for the email code.

Hide empty blocks using comment tags

Wrap part of the email content — text, a table row, or HTML code — in the tags <!--[RemoveEmpty]--> and <!--[/RemoveEmpty]-->. If all variables inside the tags return a blank value, the system removes the entire content between the tags before sending the email.

💡 The tags are written as HTML comments and do not affect the email layout.

Example: hide a table row when the passenger has no frequent flyer number.

<!--[RemoveEmpty]-->
<tr>
    <td style="width:210px"><strong>Frequent Flyer:</strong></td>
    <td>[FrequentFlyers]</td>
</tr>
<!--[/RemoveEmpty]-->

• If the variable [FrequentFlyers] contains a value, the recipient sees the row normally.
• If the variable [FrequentFlyers] is empty, the entire row (<tr>...</tr>) is removed, leaving no empty "Frequent Flyer:" parameter in the email.

12. Enable default styles

Allows applying the styles defined in Custom e-mail style settings (System Settings → E-mail) to the HTML code generated by template variables (for example, [SegmentTable]).

The styles are not applied to the rest of the email content.

13. Attach PDF document

[image]

Allows attaching a PDF document to the email. Enabling this setting opens additional configuration fields.

PDF attachment name (required) – enter the file name for the PDF attachment.

PDF body – edit the PDF document content using the built-in editor. The PDF content can be generated independently of E-mail body and uses the same set of tools and variables.

The copy from e-mail body link copies the current content of E-mail body into the PDF body field.

14. Send e-mail only once

Allows limiting email delivery to a single attempt for a given PNR at this step. If the PNR reaches this step again, the system checks whether the email has already been sent and does not send it again.

Without this setting, the system sends the email again each time the PNR passes through this step.

15. Send individual e-mail for each passenger

Allows generating a separate email for each passenger in the PNR instead of one email covering all passengers. When enabled, passenger-related variables return data only for the passenger each email was generated for. The recipient address (To field) stays the same for all emails.

16. Add calendar files

Allows attaching calendar files (.ics) to the email for PNR segments. The system creates a separate .ics file for each segment with HK status and a future date.

Overview

Applies one or more tags to a reservation instance, a reservation, or a document for later identification by schemes.

How it works

The element marks a reservation instance, reservation, or document with one or more tags so that other schemes, refund rulesets, or the Unused Ticket Tracker module can later detect and act on them.

The user selects the tag target level, then applies one or more tags at that level.

Tag target levels

Tags can be set at two scopes:

• Instance level – applied directly to the Reservation or Document processing instance.
• Object level – applied to the underlying object: the PNR or the document (ticket or EMD).

Settings

1. Title

   Specifies the name of the element as it appears on the workflow canvas. Defaults to "Set tags". The value can be edited manually.

2. Select the tag target level

   Selects the target level the tags are linked to. The available levels depend on the scheme type in which the Set tags element is used.

   PNR Processing, PNR Pricing, and PNR Redirector schemes offer these levels:

   • Instance – links the tag to the processing instance for this PNR. The tag is not detected for the same PNR when it is processed by another scheme or by refund ruleset conditions.
   • Reservation – links the tag to the PNR itself. Any scheme that processes this PNR, or the refund ruleset conditions, detects the tag.
   • Ticket – links the tag to a ticket associated with the PNR. Any ticket processing scheme, refund ruleset conditions, or the Unused Ticket Tracker module detects the tag.
   • EMD – links the tag to an EMD associated with the PNR. Any EMD processing scheme or refund ruleset conditions detects the tag.

   Ticket Processing and EMD Processing schemes apply the tag to the ticket or EMD, respectively, at two levels:

   • Instance – links the tag to the processing instance for this document.
   • Document – links the tag to the document itself (ticket or EMD).
   ℹ️

   Tip

   Tags can carry a colored label indicating their outcome type. For details on tag labels, see the Tags page under System settings.

3. Add ticket condition (document level only, for PNR processing scheme types)

   Opens a searchable list of conditions. One or more conditions can be selected. When conditions are selected, the document tag is assigned only to documents that satisfy them.

4. Tag selection area

   Displays available tags grouped by category, plus an Uncategorized tags group. Selects one or more tags to apply.

5. Create New Tag

   Opens the Add new instance tag dialog to create a tag that does not yet exist, directly from the Set tags dialog.

   ℹ️

   Tip

   The new tag is created at the level selected in Tag [object] (setting 2), and appears under the corresponding section — object or instance — on the Tags page under System settings.

Overview

Stops processing in one or more selected schemes.

Description

When triggered, the system sets the target scheme's status to Completed.

• If a next run was scheduled for the target scheme, it does not execute.
• If processing in the target scheme was paused at a Pause step, the steps that follow Pause do not execute.

Settings

1. Schemes (required) – Specifies the target scheme(s) where processing stops. Accepts one or more schemes.

ℹ Note: Schemes with a Draft status (never activated) do not appear in the list. Schemes marked with a 🚫 icon are inactive; the icon helps identify their state directly in the list.

Often used with

• Process by another scheme – has the opposite behavior: triggers processing in another scheme rather than stopping it.
• The active instance is processed in a different schema (condition) – checks whether the PNR has already been processed by another scheme.