Journey Manager (JM)
The transaction engine for the platform. |
System Manager / DevOps | 18.11
This feature was updated in 18.11.
Journey Manager allows you to search for transactions based on a wide range of criteria which can be useful when troubleshooting transactions.
To navigate to transaction support search, select Operations > Txn Support Search.
Transactions are shown page by page, with the maximum number of records per page configured via the user's preferences.
The list displays the following details:
ID: a transaction ID.
Tracking Code: a transaction's tracking code.
Form: a name of the form.
Org.: an organization associated with the form.
Time: time and date of a transaction, which can be Form Opened Time, Form Saved Time, Form Submitted Time, Last User Activity Time, Form Completed Time. This time is stored in submission.time_request.
Space: a form space where the form is hosted.
User/ Contact Email: a user name and an email address, if available.
Payment: a payment amount, for example, $10, which is displayed in black for Required payments and in blue for Completed payments.
To filter or search the transactions by one or more criteria, specify the following settings and click Search:
Reference: a transaction ID or tracking code.
Form status, which can be one of the following:
Abandoned: a transaction that has been abandoned by the user, or based on the data retention policy
Assigned: a task which is waiting to be completed by a user
Completed: a transaction that has been successfully submitted and contain all required data
Opened: a transaction that has been started by a user. When a transaction is created by a user (by starting a new form), the initial form status is set to Opened. This status will be changed once the user saves, cancels, or submits the transaction.
Saved: a transaction that has been saved by the user or automatically by the system
Submitted: a transaction that has been submitted but may require additional information, such as attachments, payment, and so on. Once the required data is collected, the transaction status will change to Completed. This status is not common for Maestro forms as all information, such as attachments and payments, are collected prior to the user submitting the form. Most Maestro forms will skip the Submitted status and will be marked as Completed after the form is submitted by the user. This is a legacy feature.
Expired: a form associated with this transaction has expired and is no longer available
Attachments.
An attachment type can be one of the following:
Completed.
Optional.
Required.
Form Name - select a form name from the dropdown list.
User / Email - provide a user name or an email address.
Receipt.
Ready: a receipt is waiting to be allocated to a receipt generator.
In Progress: a receipt is in a receipt generator's queue.
Completed: a receipt has been generated.
Error: there is an error during receipt generation. A retry may fix it.
Error - No Data: there is no XML data available to generate a receipt.
Payment, which can be one of the following:
Required:
Completed:
Error:
Pending:
Space.
Delivery.
A delivery status can be one of the following:
Completed: a transaction has been successfully delivered, based on the configured delivery channel.
Undeliverable: a delivery is not possible. Check the error logs for further details of the error.
Not Ready: a transaction is not ready for delivery yet. This is the start state before a transaction has been completed by the user. Generally, the receipt render service will kick the transaction from this state to the Ready state when the receipt is rendered.
Not Required: a delivery is not required. It may be that this form is part of a collaboration job and the delivery is to be handled separately say as a consolidation of the transaction details from all the associated forms.
Ready: a transaction is ready to be delivered. A transaction will be marked as Ready until the delivery channel is processed, or it may remain marked as Ready if a delivery channel is not configured.
In Progress: a delivery has been started but is waiting to be completed.
Paused: a transaction delivery is paused. This transaction's status can be changed by some other means, for example by a Groovy Scheduled Task.
Error: a transaction delivery has failed and is waiting to be retried.
Sent Email: a secure email has been sent and now a transaction is waiting for the user to log in and process it.
Pending: a transaction delivery is pending.
Signature, which can be one of the following:
Required:
Completed:
Completed - Deliver Manually:
Completed - Upload Scanned Copy:
Jobs.
A job type can be one of the following:
Include - transactions associated with a job are included.
Exclude - transactions associated with a job are excluded.
Start Date - the date and time you want to search from. Manager uses timestamps of several distinct transaction's life cycle states to search for transactions, for example, Form Opened Time.
End Date - the date and time you want to search until.
Manager uses timestamps of several distinct transaction's life cycle states to search for transactions, for example, Form Opened Time.
Note
The time interval is inclusive.
Email Verify.
An email verification type can be one of the following:
Click View Receipt to view a PDF receipt of the selected transaction.
Click Retry Delivery to retry delivery of the transaction. This is only available if delivery of a transaction has not been completed, but submission data is still available.
Click Retry Delivery From Scratch to attempts to deliver the submission using the current delivery details set up in the form after deleting all existing delivery checkpoints for the submission. If no delivery checkpoints exist, this is equivalent to the retry delivery option above. This is only available if delivery of a transaction has not been completed, but submission data is still available.
Click Open Saved Form to open the saved form to complete the form on behalf of the user.
Note
To use this option, you must have the Submission Save Edit permission.
Bulk Operations
You can also perform several bulk operations on multiple selected transactions. | 18.11
This feature was introduced in 18.11.
Note
To perform bulk operations, you must have the Submission Data Purge or Submission Edit permissions.
To perform a bulk operation:
Select or filter transactions you need, as described above.
Select all these transaction ID checkboxes or select the header checkbox to bulk select all filtered transactions.
Apply one of the following actions:
Click Abandon to abandon the selected transactions.
Click Transaction Purge to purge the selected transactions immediately. Active transactions will be abandoned, if they are not already abandoned.
Click OK to accept the warning message that the transactions and all the data will be purged.
Note
Transactions relating to collaboration jobs are rejected and this is recorded in the event log entry. The user is warned this has happened.
Check the event log entry to see if the purging was successful. An example of a successful message is: Submission 3090 was marked for immediate PII data purging by user [email protected].
Note
You can purge each transaction separately from the Transaction Status tab. | 18.11
This feature was introduced in 18.11.