Passo Marketplace Setup Configurations
Last updated
Was this helpful?
Last updated
Was this helpful?
The Marketplace Dashboard application needs to be installed on ACC. To do this, log in to using your username and password.
From the menu, go to the App Store, select Passo as the sales channel, choose the relevant project, and proceed with the installation.
After the installation process, go to My Applications from the left menu, select the relevant application, and navigate to its application page. Once the necessary build and deployment steps are completed, the Passo Marketplace Dashboard application will become available in the left menu of Omnitron.
After the installation, the menu will appear as shown in the screenshot.
After the deployment of the application is completed in ACC, a sales channel will be automatically created in Omnitron. The fields within this sales channel need to be filled in.
You can access the sales channel via Omnitron > Settings > Sales Channels.
Field Name
Description
Example
Information
Requirement
Channel Name
Sales Channel Name
Passo
Automatically created.
Required (Should not be changed)
Catalog Name
Catalog name created for Passo *May vary from brand to brand
Passo_Catalog
Required (Should not be changed)
Required (Should not be changed)
Channel Type
Channel Type *All sales channel types are available as a dropdown menu in Omnitron.
Sales Channel
Required (Should not be changed)
Required (Should not be changed)
Status
No processes will run unless the sales channel is activated.
Inactive
Default is set to inactive (activation is required).
Required
Schema Type
This section defines the information that needs to be stored in the sales channel settings. The data entered here is used to generate a form in Omnitron that provides the necessary information for the sales channel to operate.
A schema containing the minimum required fields for the sales channel to function is automatically created. Additionally, you can add extra fields here for any additional information you want to store (for example, information needed for the sales channel’s ERP integration).
The key-value pairs that will be included in the Channel Config are defined here. In the dictionary under the value part, the following properties are present:
key → Specifies the key used to access the information via the channel config
label → Describes how the field will appear in the form on the Omnitron sales channel settings interface
required → Indicates whether the field is mandatory (true/false)
data_type → Specifies the data type of the field (list, text, integer, bool, json)
{
"base_url": {
"key": "base_url",
"label": "Base Url",
"required": true,
"data_type": "text"
},
"access_token": {
"key": "access_token",
"label": "Access Token",
"required": true,
"data_type": "text"
},
"buffer_stock": {
"key": "buffer_stock",
"label": "Buffer Stock",
"required": false,
"data_type": "integer"
},
"category_ids": {
"key": "category_ids",
"label": "Category Ids",
"required": true,
"data_type": "list"
},
}
Default information has been entered automatically.
Required (Additions can be made, but existing fields must not be changed).
Base Url
API URL for Passo
https://fd041f331e5c46c7aca7a16abec6bbaa.lb.akinoncloud.com
Required
Access Token
default
It is pre-filled with the default value (this information is obtained from Passo).
Required
Category IDs
The main category IDs on the Passo side are checked and added here. Instructions on how to fill this in can be found under the 4th heading, “Fetching Category Tree for Sales Channel and Creating Attributes,” as shown.
f8aeb10e-f0f9-4f17-9687-60e542bdaefc
ffcc74a6-6b46-4820-91fd-d30501037aa0
It is left blank by default (the category IDs you want to use from the table should be entered here).
Required
Feature Flags
This controls whether running processes are enabled or disabled. The important point to note is that even if a particular process will not run, it must still be included here with a value of false. (Detailed information about feature flags is provided under the 9th heading, Feature Flags, as shown.)
{
"get_orders": false,
"get_cancel_orders": false,
"get_refund_orders": false,
"send_update_orders": false,
"get_updated_orders": false,
"delete_product": false,
"product": false,
"price": false,
"stock": false,
"send_refund_order_status": false,
"split_packages": false
}
The default setting is that all flags are set to false.
Required
Cargo Company Mapping
When an order is retrieved, it ensures that the order is recorded in Omnitron with a default shipping company. Additionally, if the brand does not manage the shipping processes (i.e., if send_shipping_info is not active), and if the shipping information slug coming from Passo is mapped here, the shipping company is set accordingly when the order is retrieved.
{ "default": "3",
“yurtici”: “2”
}
It is pre-filled with the default key.
Required
Use Cargo Label
If the brand does not manage the shipping processes (i.e., send_shipping_info is not active) and a shipping label is to be generated when the order is retrieved from Passo, this setting must be activated.
Note: The shipping label is in a fixed PDF format.
Inactive
It is left blank by default.
Optional
Use Neighborhood
Whether the neighborhood information in the address data will be used when creating an order is determined by this setting. If active, the neighborhood information included in the shipping and billing addresses on the order will be processed during the address creation step of the related order in Omnitron. If inactive, the neighborhood information will not be used when the order is pulled into Omnitron.
Inactive
It is set to inactive by default. If the company’s ERP requires neighborhood information, this field should be activated so that Omnitron can use the neighborhood data.
Optional
Order Number Format
When pulling order data from Passo to Omnitron, the order number is formatted according to this setting. If this value is left blank, the order number will be recorded in Omnitron by default as “{orderNumber}-{id}”. Here, “orderNumber” corresponds to the “order_number” field on the Passo side, and “id” corresponds to the “number” field.
FD-{orderNumber}-{id}
It is left blank by default.
Optional
Default Reason ID
If the reason ID included in the return data pulled from Passo is not found in the Refund Reason Mapping, the refund data will be retrieved and recorded in Omnitron using the Omnitron refund reason ID entered in this field. (The ID information can be obtained via {omnitron_url}/api/v1/channel/{channel_id}/cancellation_reasons/?cancellation_type=refund&is_active=true)
5
It is left blank by default.
Required
Refund Reason Mapping
{
“f3909f53-a535-40cc-8d50-de0cd047aedd”:”7” ,
“f488f79f-503f-4787-a8ef-6a37b085b5e1”:”5”
}
It is left blank by default. (If left blank, when return data is pulled from Passo, the return reasons will be recorded using the “Default Reason Id” specified in the previous step.)
Optional
Refund Start Date
This is the initial start date from which returns will begin to be pulled. The format is “yyyy-MM-ddTHH:mm:ssZ”.
2023-07-01T00:00:00Z
It is left blank by default.
Optional
Failed Integration
Records that encounter errors during the integration process are held for a certain period as a penalty. (Detailed information is provided under the 3rd heading, Failed Integration Settings, as shown.)
{
"order": {
"RETRY_INTERVAL": 28800,
"EXPIRATION_DATE": 57601,
"MAX_RETRY_COUNT": 3
},
"DEFAULT": {
"RETRY_INTERVAL": 28800,
"EXPIRATION_DATE": 57601,
"MAX_RETRY_COUNT": 2
},
"product": {
"RETRY_INTERVAL": 28800,
"EXPIRATION_DATE": 57601,
"MAX_RETRY_COUNT": 2
},
"productprice": {
"RETRY_INTERVAL": 28800,
"EXPIRATION_DATE": 57601,
"MAX_RETRY_COUNT": 2
},
"productstock": {
"RETRY_INTERVAL": 28800,
"EXPIRATION_DATE": 57601,
"MAX_RETRY_COUNT": 2
},
"sent_to_remote": {
"EXPIRATION_HOUR": 6
}
}
It is pre-filled by default.
Required
Send Shipping Info
This setting determines whether the shipping process will be managed by Passo or by the brand.
Inactive
It is set to inactive by default. (If inactive or not selected, the shipping process is managed by Passo. If active, the brand manages the shipping process itself.)
Optional
Cancellation Reason ID
This specifies the reason ID that will be used when canceled orders pulled from Passo are recorded in Omnitron. (The ID information can be obtained via the endpoint {omnitron_url}/api/v1/channel/{channel_id}/cancellation_reasons/?cancellation_type=cancel&is_active=true)
4
It is left blank by default.
Required
Cancel Reason Mapping
{
“f3909f53-a535-40cc-8d50-de0cd047aedd”:”1” ,
“f488f79f-503f-4787-a8ef-6a37b085b5e1”:”3”
}
It is left blank by default. (If left blank, when cancellation data is pulled from Passo, the cancellation reasons will be recorded using the “Cancellation Reason Id” specified in the previous step.)
Optional
Reject Item Reason
This is the reject (return rejection reason) information that will be used during the approval/rejection process of the return data pulled with the refund order flow in the order.
Damaged
Left blank by default.
Optional
Attribute Set Strategy
This is a strategy setting that determines which attribute set the products belong to.
CategoryNode
It is pre-filled by default.
Required (Should not be changed)
Use Channel ID In Address Mapping
If desired, the brand can activate this field to perform address mapping on a per-channel basis. When this field is activated, the channel ID is prefixed to the address data during the mapping process, and searches are conducted using the channelId_address information with a sales channel filter.
Inactive
It is left blank by default.
Optional
Buffer Stock
This is the value to be deducted from the product’s available stock when sending stock data to Passo. If no value is entered, the full available stock will be sent to Passo.
3
It is left blank by default.
Optional
Waybill Option
In order updates sent to Passo, if the status of the relevant order is Shipped or Delivered, and the enabled field in this setting is set to true, the waybill_number field will be updated as follows:
– If the invoice number of the order is available, it will be used.
– If not, the value entered in the default field will be used.
{
"enabled": true, "default": "999"
}
{
"enabled": false, "default": ""
}
Optional
Send Cancel Reason ID
This is the ID information from Omnitron that will be used when sending cancellation data — which was created in Omnitron (i.e., not received from Passo) — to Passo.
You can retrieve the ID via the following endpoint:
{omniton_url}/api/v1/channel/{channel_id}/cancellation_reasons/?cancellation_type=cancel&is_active=true
Note: This ID must be different from the Cancellation Reason ID and the IDs used in Cancel Reason Mapping, as cancellation requests coming from Passo are distinguished based on the reason.
10
It is left blank by default.
Optional
In the integration process, records that result in errors are temporarily penalized and delayed from being retried for a certain period. The values for "RETRY_INTERVAL" and "EXPIRATION_DATE" should be provided in seconds.
RETRY_INTERVAL: Specifies how long (in seconds) the system should wait before retrying after an error occurs.
EXPIRATION_DATE: Specifies how long (in seconds) a failed integration record remains valid before it expires.
MAX_RETRY_COUNT: Indicates how many more times the system should retry after a failure. It will not retry again until the RETRY_INTERVAL has passed.
sent_to_remote: Defines the maximum time (in seconds or as an hourly value) to wait for a response from the marketplace for bulk requests. For example: { "EXPIRATION_HOUR": 360 }.
Any updates made to these values will take effect in the subsequent operations. For example, if a SKU's stock update previously entered the penalty queue with a retry interval of 3 hours, and this retry interval is later updated to 2 hours, then after the initial 3-hour penalty, if the stock update is retried and fails again, it will enter the penalty queue with the new 2-hour interval.
We use the failed integration settings to temporarily penalize the data sent from Omnitron to Passo when an error occurs. For instance, if a product attribute is missing during product submission, these settings allow a certain period to fix the error before retrying.
First, from Passo > Dashboard Visit the link to view the main categories, obtain the main category ID information to be used and add these IDs to the Category Ids field in the channel config.
The category tree is fetched based on the added Category Ids within the sales channel.
After the category tree is fetched into Omnitron, it can be viewed under the Category Management section when the relevant Passo is selected as the Sales Channel.
After this process completes successfully (which can be monitored via logs), the flow that fetches the attributes will run. Once the attribute-related operations are finished (i.e., the Default Attributes flow has run and completed successfully), you can proceed to the next steps.
After the category tree retrieval step is completed, the user needs to perform category mappings via the Mapper.
The Akinon Mapper function within Omnitron allows users to configure and manage the attribute values of the products they want to sell on marketplace sales channels according to the marketplace’s requirements. Additionally, it provides the capability to verify whether the attributes and their values are correct before the products go live for sale.
You can find examples of custom mappings that you can create for Passo in Appendix 2.
Products must be added to the relevant category tree on the Passo side. Each product should be assigned to only one category. Otherwise, errors will occur during the submission process.
When the Passo marketplace application is installed on the relevant brand’s Omnitron, it appears as “Passo” in the left-hand menu.
The dashboard data related to the Passo marketplace application is displayed on this screen.
TOTAL SKUS IN CATALOG The number of SKUs that are of type simple and active status in the related catalog.
NUMBER OF SKUS ON SALE The number of SKUs that have been sent to the marketplace and are currently on sale.
TOTAL SKU DIFFERENCE The number of SKUs that are in the catalog but not on sale in the marketplace. This section compares the sellable products in Omnitron with the products currently on sale in the marketplace. That is, products considered here have a price in Omnitron, stock greater than zero, a category, product image, and are present in the catalog.
NUMBER OF SKUS WITH PRICE DIFFERENCES CORRECTED The number of SKUs with price differences between Omnitron and the marketplace. If differences exist, a separate task has been run to correct the differences.
TOTAL STOCK QUANTITY IN CATALOG The total stock quantity of all products in the marketplace catalog.
TOTAL STOCK QUANTITY ON MARKETPLACE The total stock quantity of products currently on sale in the marketplace.
TOTAL STOCK DIFFERENCE Stock quantity of products that are in the catalog but not on sale in the marketplace.
TOTAL NUMBER OF SKUS WITH STOCK DIFFERENCES The number of SKUs with stock differences between Omnitron and the marketplace. If differences exist, a separate task has been run to correct the differences.
This screen contains logs and reports.
The logs of the flows are displayed on this screen.
Category Node This flow fetches the entire category tree structure of the main categories entered in the channel settings into Omnitron.
Category Attribute and Values This flow fetches the category attributes entered in the channel settings into Omnitron.
Default Attributes This flow prepares predefined fields (such as remote_id, title, etc.) for the mapping process during product submission.
Product This flow sends products entered in Omnitron to the marketplace.
Product Delete This flow removes products deleted from the Omnitron catalog from sale on the marketplace.
Stock This flow sends the updated stock information of products with stock updates in Omnitron to the marketplace.
Price This flow sends the updated price information of products with price updates in Omnitron to the marketplace.
Order Create This flow fetches orders from the marketplace into Omnitron.
Order Update This flow updates orders on the marketplace when order status, invoice, or shipping tracking number is updated in Omnitron.
Order Cancel This flow updates the statuses of canceled orders on Omnitron when they are canceled on the marketplace.
Order Refund This flow updates the statuses of refunded orders on Omnitron when they are refunded on the marketplace.
Updated Orders This flow updates the statuses of orders on Omnitron when their statuses change on the marketplace.
Approve / Reject Refund Order This flow sends the approval or rejection information of refunds approved/rejected in Omnitron back to the marketplace.
Split Packages This flow transmits order split requests coming from Omnitron or another OMS system to the marketplace.
Compare Attributes This flow updates the statuses of category attributes in Omnitron when their statuses change on the marketplace.
Send Cancel Order Items This flow updates the statuses of canceled orders on the marketplace when they are canceled in Omnitron.
This screen provides reporting on products that have been added to the catalog in Omnitron but are not listed for sale on Passo. It highlights discrepancies between the price and stock information in Passo and the corresponding data in Omnitron.
Creating Alarms and Notifications The Marketplace Dashboard is an advanced automation platform designed to facilitate e-commerce integrations. Alarms and notifications play a vital role in informing users about critical events such as integration errors, data delays, and successful completions. Thanks to real-time alerts, users can quickly detect and resolve integration issues, ensuring smooth operation of e-commerce processes. This, in turn, helps deliver the best shopping experience to end customers.
Benefits of Alarms and Notifications
Real-Time Issue Detection: Alarms instantly identify integration errors, ensuring accurate data flow between systems.
Proactive Problem Resolution: Alarms enable timely intervention for integration issues, minimizing downtime and operational impact.
Enhanced Data Integrity: Alarms prevent data delays or interruptions, supporting consistent and accurate data processing.
Optimized Customer Experience: Rapid resolution of integration problems keeps order, stock, and product information always up-to-date, providing customers with a seamless shopping experience.
Enhanced Operational Efficiency: Alarms keep users informed about critical events, allowing them to focus on strategic tasks.
Data-Driven Decision Making: Alarms provide valuable insights to optimize integration processes.
Reduced Downtime: Early detection of issues minimizes system interruptions and prevents revenue loss.
Customizable Alerts: Akinon Marketplace Dashboard offers flexible alarm customization to fit business needs.
Seamless Cross-Platform Communication: Alarms facilitate communication and synchronization between different e-commerce systems.
By leveraging alarms in the Akinon Marketplace Dashboard, users can effectively monitor and manage e-commerce integrations, ensuring a reliable, efficient, and customer-centric shopping experience.
Alarm and Notification Setup Steps
Step 1: Accessing Alarm and Notification Settings The Marketplace Dashboard is not a standalone product opened via a separate URL. To access it, first go to the Omnitron left menu, click on the Marketplace under the Sales Channels menu, and then select Marketplace Operations from the dropdown menu.
Step 2: Create a New Alarm and Notification Rule Click the + Create New Alarm button located at the top right corner of the “Alarms” screen.
In the opened settings page, select a Flow Name from the dropdown list.
Set the alarm conditions based on specific criteria such as error rate, flow duration, time interval, and metric value.
Select a notification channel and add the email addresses of the individuals or teams who will receive the notifications. (There is no limit on the number of email addresses.)
Step 3: Save the Alarm and Notification Rule After successfully configuring the alarm rule, click the Save button to save the alarm.
Thanks to the power of alarms and notifications in the Akinon Marketplace Dashboard, e-commerce integrations become more efficient. Real-time monitoring allows instant intervention to issues, ensuring data accuracy and delivering a flawless customer experience. Customizable alerts enable teams to stay informed and make data-driven decisions.
Error Rate: If the number of errors within the specified time interval exceeds the defined limit, the alarm is triggered.
Average Flow Time: If the average processing time of the flow within the specified time interval exceeds the set threshold, the alarm is triggered.
This screen is used for triggering flows.
The steps to follow for common errors found in logs are as follows:
“Stock data not found” Indicates that the product’s stock data is missing. Stock data needs to be added for the related product.
“Price data not found” Indicates that the product’s price data is missing. Price data needs to be added for the related product.
“… attribute is required” Indicates missing mapping for the specified attribute. Mapping should be done as described in Section 5 (Marketplace Mapping).
“Unreported order of ERP can not be canceled” Indicates that the related order has not yet been sent to the ERP system. The order must be sent to ERP to proceed with the cancellation.
“Address is not valid. channel: 137 code: 137_Merkez model: Township city id: .., city name: …” Indicates that the Township in the address data of the order requires mapping.
Note on Product Triggering: Triggering a product from the dashboard only performs a create operation. If you want to trigger a product update, it must be done via CSV upload under “Update Bulk Product Version Date” in channel settings (top right), using the “Update via File Upload” option.
Stopping the sending of faulty products or resending products that failed to send: Faulty products are retried for a certain period according to the rules defined in the Failed Integration settings within the channel configuration. For products whose retries have stopped according to this rule, manual triggering is required.
To remove products stuck in this state from the penalty queue: Go to Omnitron’s right menu, navigate to Settings > Sales Channels, select the relevant channel, and on the opened page, use the “Update by Uploading Files” button located to the left of “Delete Bulk Failed Integration” at the top right to upload a CSV file and clear these products from the failed integration queue.
If too many faulty products accumulate in the queue, since processing is done in batches of 50, the queue may not proceed to the next products. There are two solutions for this:
Urgently fix errors related to mapping, catalog, stock, price, etc., and then trigger a CSV upload afterwards.
Properly configure the Failed Integration settings in the channel settings with appropriate time intervals.
For the error “Failed to suggest product to catalog.”, if the issue is related to attribute values, the Category Attributes flow should be run to fetch updated attribute values, and if necessary, the Compare Attributes flow should also be executed.
Errors received after CSV upload:
sku cannot identify please check your csv file. Header value should be set this: sku This error occurs if the first row of the CSV file is not “sku.” The CSV file must be created according to the template provided on the trigger screen.
The relevant SKU not exists in Omnitron. Request URL: {url} This error occurs if the related SKU does not exist in Omnitron.
The relevant record is processing in another queue, LocalBatchId: {local_batch_id} This error appears if the product being sent is triggered again while the sending process is still ongoing. Check the product logs and wait for the flow in "Waiting" status to complete. After completion, you can filter the logs by SKU to check the final status.
The relevant record is not in queue. The item may have been penalized or check product is saleable This error occurs if the product is inactive or not in the catalog.
Order Update (send_update_orders) flow and unresolved orders on MPD side:
If there is an ongoing or opened return process for the order, it will not be updated.
The tracking number value will only be sent if “Send Shipping Info” is marked active. For details, check the “Feature Flags” section.
The order status cannot be updated retroactively. Therefore, manual intervention in the flows is not recommended.
The default frequencies for execution are as shown in the table below. These values can be modified by the Marketplace team.
Flag
Description
Frequency
get_orders
This feature flag enables pulling orders with the “Preparing” status from Passo to Omnitron by looking back 12 hours from the flow’s execution time.
Before activating this flag, the settings mentioned under the second section (Sales Channel Definition) — Use Neighborhood, Use Channel Id In Address Mapping, Use Cargo Label, Cargo Company Mapping, Send Shipping Info, Order Number Format — must be properly configured.
It runs every 5 minutes.
get_cancel_orders
It pulls the canceled completed claims from Passo going 12 hours back from the flow's run time and processes the cancellation in Omnitron, ensuring that the cancellation plan count does not exceed 6. Before activating this flag, the Cancellation Reason Id and Cancel Reason Mapping settings in section 2 (Sales Channel Definition) must be properly configured.
It runs every 5 minutes.
get_refund_orders
Refund claims with open or waiting status on the Passo side are fetched, and the claim lines are retrieved to create a refund request in Omnitron. Before activating this flag, the Default Reason Id, Refund Reason Mapping, and Refund Start Date settings in the second section (Sales Channel Configuration) above must be properly configured.
It runs every 5 minutes.
send_update_orders
It enables sending the order statuses ("Preparing", "Shipped", "Delivered"), invoice information (invoice_number, invoice_date, e_archive_url), and tracking details (tracking_number, tracking_url, shipped_date) to Passo. Before activating this flag, the Send Shipping Info and Waybill Option settings in the second section (Sales Channel Configuration) above must be properly configured.
With this flow, the invoice and order status are updated. The tracking number is sent only if Send Shipping Info is enabled.
It runs every 5 minutes.
send_split_packages
It operates via an outbound trigger sent externally by the OMS.
product
It ensures that products added to or updated in the catalog are sent to Passo along with their price and stock information. Before activating this flag, the Buffer Stock setting in section 2 (Sales Channel Configuration) above must be properly configured.
It runs every 5 minutes.
delete_product
It ensures that the stock of products removed from the catalog is set to zero on the Passo side.
It runs every 5 minutes.
price
It ensures that the prices of products that need to be updated are sent to Passo.
It runs every 5 minutes.
stock
It ensures that the stock quantities of products that need to be updated are sent to Passo. Before activating this flag, the Buffer Stock setting in section 2 (Sales Channel Configuration) above must be properly configured.
It runs every minute.
get_updated_orders
If the shipping processes are managed by Passo, this flag enables pulling orders with the status “Shipped” or “Delivered” from Passo going back 24 hours from the flow run time, and updates the status and tracking_number (for “Shipped” status) on an item basis in Omnitron. Before activating this flag, the Send Shipping Info setting under section 2 (Sales Channel Definition) must be properly configured.
It runs every morning at 06:00.
send_refund_order_status
It enables the approval or rejection of the generated refund request on the Passo side.
It runs every 5 minutes.
send_cancel_order_items
It ensures that the cancellation information created in Omnitron for the order is sent to Passo. Before activating this flag, the settings in the 2nd section (Sales Channel Definition) — Send Cancel Reason Id, Cancellation Reason Id, and Cancel Reason Mapping — must be properly configured.
Important Note: It is crucial to distinguish between the cancellation reasons used in the Order Cancel flow and the cancellation reasons used in this flow. In other words, when performing the cancellation here, the cancellation reason corresponding to the IDs in Cancellation Reason Id and Cancel Reason Mapping in the channel config should not be selected. If selected, the cancellation will not be sent to Passo.
It runs every 5 minutes.
It is pre-filled as .
This is the fixed token information to be used in requests sent to Passo. (You can check how to access the token information at )
For return processing, the return reason information from Passo is mapped to the return reason information in Omnitron. The key should be the ID from Passo (those with type refund found at ), and the value should be the reason ID in Omnitron. (The ID information can be obtained via {omnitron_url}/api/v1/channel/{channel_id}/cancellation_reasons/?cancellation_type=refund&is_active=true)
For cancellation processing, the cancellation reason information from Passo is mapped to the cancellation reason information in Omnitron. The key should be the ID from Passo (those with type cancel found at ), and the value should be the reason ID in Omnitron. (The ID information can be obtained via {omnitron_url}/api/v1/channel/{channel_id}/cancellation_reasons/?cancellation_type=cancel&is_active=true)
You can find detailed documentation about the Mapper and the necessary definitions to be made in the Mapper from here.
For triggering processes, refer to the document.
Detailed information can be found in the document at the link: .
