Processing history helps you see exactly what happened during each run – so you can investigate issues, validate system behavior, or just stay in control.
Processing history displays a log of all processes that have run for a specific instance.
Troubleshooting & debugging
Processing history shows which path a block followed and why. This helps quickly identify misconfigured rules or unexpected input values.
Optimizing processes
Reviewing how often certain conditions are met can reveal unnecessary steps or inefficiencies. You can then adjust the logic to streamline workflows.
Ensuring automation works as expected
Reliable automation depends on clear, predictable logic. Understanding how grouped conditions and inversions are evaluated helps ensure that rules behave correctly.
Supporting transparency and audits
When decisions need to be explained – such as in ticketing, finance, or compliance – a clear processing trail provides the necessary transparency.
An object (PNR or document) can be processed by multiple schemes which create an individual instance.
Each time a scheme runs, it sends a request to the GDS and starts a new session.
Since the data in the PNR may change between runs, the processing flow can differ – even when using the same scheme instance.
To open the processing history, click the icon at the end of the instance row on the Reservation Processing page.
Each run is saved as a session in the processing history. A session captures the state of the PNR or document at the time it was processed.
Sessions are displayed from bottom to top and grouped by date, making it easy to follow the sequence of processing attempts across longer histories.
Sessions (repeated runs of an object through the workflow) will continue as long as the workflow conditions or design postpone processing. At the end of each session, you’ll see when the next run is scheduled.
If no further runs are expected, the status will show Finish.
Sessions are made up of steps. They provide the details of how the session was processed.
Click a session row to view details.
Steps consist of processing events. Each event is assigned a number.
Hover over the end of the step row – the dash icon will appear, showing the event number in a tooltip.
Once you have the number, you can also use it to configure conditions like Events in the processing history more precisely.
The event at the bottom shows the initial reason why the PNR was processed in this instance.
Common scenarios include:
- The PNR was received from a GDS queue
- The run was redirected to this scheme by another scheme
- The PNR was launched manually
You can also use event number to search for specific instances.
Learn more: Search and filters
For a more detailed view, adjust the category level:
- Info (default): Shows only action blocks.
- Trace: Displays the full processing path, including how conditions were evaluated.
- Debug: Provides additional technical details.
- Warning or Error: Shows only steps that include warnings or errors.
If you need a more detailed view of the processing history, switch to the Trace level.
It shows the full processing path of the PNR within the scheme – not just how each action was executed, but also how the system evaluated Conditions during processing.
Icons to the right of the instance row represent important events that occurred during the session:
- Sent E-mail
- Completed optimization
- Issued ticket
- Error
- Warning
Click them to see details.
In each session row, you can also navigate to more details:
- View web logs
- View scheme path in this particular session
Logs follow a request–response format and show which data was requested, how it was requested, and what responses were received.
A scheme opened from the processing history will look slightly different – it highlights only the steps that were actually executed during that processing run.
This scheme will display a Processing history label in the top left corner, showing the PNR number, the scheme name, and the date and time of processing.
Hover over or double-click an element to see its configuration.
A single click on an element will open an additional menu:
- Question mark: quickly create a support ticket with a link to this step
- Link: copy link to the element
- Info icon (i): view detailed processing information, including which checks were performed
From here, you can edit your scheme or view its current version.
Understanding how grouped conditions and inversions are evaluated can help you read the processing history more accurately.
When conditions are combined with OR, the block follows the OK path if any group is satisfied.
The system checks condition groups in order and stops at the first group that returns OK.
For example, in the case below, the first group failed because the tag was found, but the condition required it to be absent. The system then moved to the second group, which was met, resulting in an overall OK outcome.
If the same rule were ordered differently, the system might find OK in the first group and skip checking the second one.
You’ll see this in the history – unprocessed groups are marked accordingly.
The system would find an OK result in the first group and wouldn’t check the second group at all.
In the image below, you can see that the second condition group wasn’t evaluated because the first one returned OK.
If conditions are combined with AND, all groups must be met.
If any group fails, the remaining groups won’t be evaluated. The history will show Not processing for those skipped groups.
Keep this in mind when building complex conditions – group order and logic type (AND/OR) directly impact what gets processed.
In case you need support, copy the link and share it with our team – or create a case directly from the processing history view.
- Use category levels wisely to get the right amount of detail for your task.
- Check grouped conditions carefully: Be mindful of order and logic (AND/OR) when checking complex rules perform.
- Use icons for quick actions: Jump to logs, see the scheme path, or get support directly from the history view.
- Stay consistent: Reviewing the processing history regularly helps catch issues early and keeps your workflow smooth.