This article will review:
Frequently asked questions (FAQ's) for Partnerize Salesforce Commerce Cloud Integrations
Index
Overview
This guide will cover the most common FAQ's for Partnerize Salesforce Commerce Cloud Integrations.
FAQ's
Below are answers to the most commonly asked questions regarding the implementation of the Partnerize Salesforce Commerce Cloud Integrations.
Q - Can this be tested on a staging environment first?
A - Yes. However, you can't have more than one PZ tag with the same name.
There are no problems with testing the integration on a staging environment first, but you can not have more than one PZ tag with the same name.
Salesforce uses a strict naming convention when connecting to the API to create the pz tag.
If a brand needs to test on a staging environment first, we need to delete the tag before this can created on the live environment.
Please reach out to our support team for more information on this request.
Q - How should a developer manage order status updates between Salesforce Commerce Cloud and the tracking platform to account for returns?
A- The integration utilizes a specific synchronization job to ensure transaction statuses remain aligned across both platforms. When an order is initially captured following a successful purchase, it is recorded with a pending status. Once the synchronization job is enabled and executed, updates made within the Salesforce environment will automatically reflect in the tracking system. It is critical to schedule these job executions in accordance with the established return window to ensure that items are only moved from pending to approved once the possibility of a return has passed.
Q- What are the limitations of the standard cartridge when handling partial returns and how can they be mitigated?
A- The standard cartridge is designed to automate validations for full order returns but does not natively process partial returns where only specific items within a multi-item order are rejected. To manage partial returns, developers must utilize unique item identifiers created for each individual product within a transaction. These specific item-level identifiers allow for granular validation, enabling a developer to manually reject a single returned item while approving the remainder of the order. Alternatively, automated item-level validation can be achieved by implementing a custom solution via the platform API.