Pre-Support Checklist

Before reaching out for support, please review the following steps.

Over 90% of errors are related to licensing, permissions, or validation issues in the destination org.

</aside>

Consult the Error Message:
- Deployment Activity Log: For real-time feedback during a deployment, use the "Deployment Activity Log" to see error, warning, and information messages as they occur. Refer to the pertinent Success Community article for more details.
- Error Database: Check the Prodly Error Database for your specific error message. You can find this on the success.prodly.co site.
Verify Orgs and Permissions:
- Active License: Ensure your Prodly managed package license is active. If you see an error about an "inactive license for organization ID," you must contact support. Refer to the pertinent Success Community article for more details.
- Active User: The user specified in the connection must be active. If not, delete the connection and recreate it with an active user. Refer to the pertinent Success Community article for more details.
- Admin Permissions: The Salesforce user account creating a connection must have the Prodly AppOps Admin permission set. Refer to the pertinent Success Community article for more details.
- Schema & Field Access: The connection user must have access to all schema objects and fields selected in the data set in both the source and destination orgs. Refer to the pertinent Success Community article for more details.
Check Org & Data Set Configuration:
- Metadata First: Confirm that all metadata deployments (via DevOps tools or change sets) were completed before starting the data deployment. Schema discrepancies are a high-risk factor for record failures. Refer to the pertinent Success Community article for more details.
- CPQ Triggers: For CPQ deployments, ensure that CPQ triggers are disabled in the destination organization. This is a critical best practice recommended by Salesforce to prevent errors and access issues on an incomplete configuration. Refer to the pertinent Success Community article for more details.
- Schema Settings: In the Data Set Editor, ensure the "Schema Org" and "Destination Schema Org" point to the correct organizations, especially if objects or fields appear to be missing. Refer to **How-To: Disable Events During Deployments ****and **Workaround for PriceRule and PriceRule2 Conflict for Lookup Query Records ****for more details.
- Lookup Filters: If you receive a FIELD_FILTER_VALIDATION_EXCEPTION, check the lookup filter criteria defined on the object in the destination org to ensure the data you are deploying meets the requirements. Refer to the pertinent Success Community article for more details.
Contact the Prodly AI Support Agent:
- If the steps above haven't resolved your issue, reach out to Prodly's AI Support Agent. It can help troubleshoot common problems and, if it’s unable to resolve the issue for you, will automatically create a support case on your behalf. You can start a conversation with the agent from the sidebar in the Release tab.

Common Problems & Solutions

This section details specific errors and common issues you may encounter and how to resolve them.

Data Loading & Deployment Errors

Problem / Error Message	Solution(s)	Source Document(s)
`INSUFFICIENT_ACCESS_OR_READONLY`	The connection user lacks access to the schema objects in the data set. Verify user permissions.	Troubleshooting Generic Data Set Errors
`CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY` (e.g., Too many SOQL queries)	An unmanaged trigger in the destination org is failing. Use the Event Control feature in the data set to temporarily disable the problematic trigger during deployment.	**Troubleshooting Generic Data Set Errors

How-To: Disable Events...** | | FIELD_FILTER_VALIDATION_EXCEPTION | Data being deployed does not meet the criteria of a lookup filter on an object in the destination org. Navigate to the lookup field on the object in the destination org's Setup and review or adjust the filter criteria. | Troubleshooting Generic Data Set Errors | | INVALID_CROSS_REFERENCE_KEY or INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY | This typically means lookup field data is missing in the destination. The error record ID usually points to the lookup field. To fix this, either include the necessary parent/child relationships in the data set or use the "Copy Relationship Value" setting on the field. | Troubleshooting Generic Data Set Errors | | REQUIRED_FIELD_MISSING | A required field in the destination org is not being populated. You may need to temporarily make the field not required in the destination org's setup. | Troubleshooting Generic Data Set Errors | | Apex CPU Timeout when viewing a Data Set | This can happen if a data set has too many relationships to render. To bypass the custom viewer, navigate to Setup → Data Set object → Buttons, Links, and Actions, edit the "View" option, and set the "Salesforce Classic Override" to the standard view. Remember to change it back after making your updates. | Apex CPU Timeout Issues when viewing Prodly VisualForce Pages | | Price Rule deployment fails with REQUIRED_FIELD_MISSING | For customers with older Salesforce CPQ versions, a conflict between PriceRule and PriceRule2 objects can occur. In the Price Rule data set, navigate to the Lookup Query relationship and include both PriceRule and PriceRule2 from the parent relationships tab. | Workaround for PriceRule and PriceRule2 Conflict... | | Deployment includes extra, unwanted CPQ Product records | This is often due to product bundling. Products in your query may be options for other products, which are then pulled into the deployment. • Review Relationships: Check the pre-built Product data set and remove unneeded relationships. • Enforce Strict Query: Enable the "Enforce Strict Query Filter" setting on parent relationships in the Data Set Editor to exclude records that don't meet the root object's query criteria. | Using a Query Filter for CPQ Product Data Set | | Records fail due to validation rules or conditional dependencies (e.g., deploying active contracts) | Use the Delay On Insert or Deploy Last feature on the specific field. This allows Release to insert a temporary value during the initial deployment and then updates it with the actual value after other dependent records are processed or at the end of the entire deployment. | **How-To: Manage Records with Expected Field Values…

Deploying Custom Conditions** | | Hard-coded Record IDs in text fields are different between orgs | Use Text ID Mapping. First, create and deploy a data set for the object that the ID belongs to (e.g., the Document object for a logo ID). Then, in the data set for the record containing the hard-coded ID (e.g., Quote Template), use the Text ID Mapping property on that field to link it to the object you just deployed. | How-To: Migrate Hard-coded IDs Across Orgs with Text ID Mapping |

To resolve these types of messages consider the following options:

Adjust data in source to meet destination data requirements.
Use the Event Control feature in your Data Set to deactivate platform automations causing data loading issues. See additional help at Event Control.
Use settings on Object Fields in the data set to condition data to meet destination org needs.
Adjust events and validations in destination or adjust to accept source data. Additional resources: Delay On Insert.

Performance and Duplicate Record Issues

Problem / Issue	Solution(s)	Source Document(s)
Data deployments are running slowly.	Multiple factors can impact runtime:
• Bulk API Monitoring: Check if other data load jobs are running in your Salesforce org, as Release can only move as fast as Salesforce processes the records.
• Data Scope: Reduce the number of objects, fields, records, and relationships in your data set if possible.
• Use VEID: Virtual External ID (VEID) is faster than Standard Upsert because it references Salesforce IDs directly rather than querying multiple fields.
• Bulk Batch Size: Leave the "Bulk Batch Size" setting blank in the Data Set Editor. This allows Release to use the maximum of 10,000 records per API call, reducing the total number of calls.	Optimize the Runtime of Data Deployments
Duplicate records are created when using Virtual External ID (VEID).	This happens when the VEID mapping is not established or is incorrect. To avoid this:
• Deploy to a Clean Org: Start with a new org that has no reference data.
• Use Refreshed Orgs: Deploy between two orgs that were refreshed from the same production org at the same time.
• Use One Control Org: Do not switch between control orgs, as the VEID mapping is stored in the control org and is not synchronized.	**Avoiding Duplicates Using VEID

Explained: Record Matching with Release** | | I need to free up memory in my control org. | You can delete deployment results from the Prodly Admin tab. • Delete Deployment Record Results: Deletes only individual record results, preserving the high-level deployment activity history. • Delete All Deployment Results: Deletes all history and result records. This cannot be undone. Use this only as a last resort. | Remove Deployment Result Records From Your Control Org |

Pre-Support Checklist

Common Problems & Solutions

Data Loading & Deployment Errors

Performance and Duplicate Record Issues

Prodly Release Connection Errors