Sometimes things don't go quite according to plan. To help you resolve those situations, consult the scenarios below. Can't find your situation? We're continuously expanding this article, so please create a ticket if your situation is not covered in this article.
Troubleshoot Checklist
- Ensure that your Pull Query would return results
- Ensure that the Pull Mapping matches your query
- Ensure that your Mapping has the appropriate "fields_" prefixes in Sandbox
- Ensure that your records will have appropriate values in CustomerGauge Fields that have additional validation or are required
Below are the list of common issues covered in this article.
- A custom field doesn't come through
- The Pull Message says "Pull failed because of Prepared xml is not a valid xml."
- My company_number field is not being populated
- A field's value doesn't come in, while Workbench returns the value.
- (Some) data doesn't come in from Sandbox
- The number of records pulled in don't match with my expectations
- My Formula field is not being pulled in
- Certain fields return the value 'true' when they're blank
- "Element {}item invalid at this location"
- A date/datetime value is not pushed back in the correct format
Troubleshooting issues during Pulling
A custom field doesn't come through
In some rare cases, you might be adding new custom fields to your Salesforce objects, and you'd want to pull some of those into CustomerGauge. If you're experiencing that these custom fields are pulling in blank values, your WSDL file might pre-date the creation or updates of these fields.
To remedy this, you can do the following:
- Download a new WSDL file from Salesforce
- Update your integration with the new WSDL file
The Pull Message says "Pull failed because of Prepared xml is not a valid xml."
This error usually occurs when your query results 0 records.
To remedy this, you can do the following:
- If you're doing repetitive testing, it's likely that you may have forgotten to change the Flag field, so that it gets picked up again
- Ensure that your query would result data through the SOQL Workbench
My company_number field is not being populated
If you're pulling data into "company_number", but forgo to also pull data into "company", it won't be stored. We use the value provided in "company" as the unique identifier of our company object, on which "company_number" resides.
To remedy this, you can do the following:
- Ensure that you're also providing an identifiable value (something that allows you to identify that particular Account) into "Company". This will commonly be "Account_Name".
A field's value doesn't come in, while Workbench returns the value.
If your query works well in the SOQL Workbench, but the data does not get stored in CustomerGauge. In this case, there are 2 possible issues that needs to be checked.
- Pull-mapping: The pull mapping is case-sensitive; please ensure that each field has the same capitalization as it shows in the API field names in Salesforce.
- WSDL file: SOQL does not need WSDL however the integrations need the WSDL file to pull data. If the WSDL file used is obsolete and there are any changes to object structure in your salesforce, you'll need to fetch and upload the latest WSDL file in the integration.
(Some) data doesn't come in from Sandbox
Sandbox acts slightly different than Enterprise. If you're not getting data in fields where you expect to pull data, you may be missing "fields_" prefixes in your mapping.
To remedy this, you can do the following:
- For each field in your query, make sure it's in your mapping
- Make sure each field except Id is prefixed with "fields_"
- Wherever a period "." is in your query, you'll want to replace it with "fields"
For example;
SELECT
Id,
FirstName,
LastName,
Email,
Account.Name
FROM
Contact
would reflect in the following mapping;
{
"number_customer": "{Id}",
"first_name": "{fields.FirstName}",
"last_name": "{fields.LastName}",
"email": "{fields.Email}",
"company": "{fields.Account.fields.Name}"
}
The number of records pulled in don't match with my expectations
Regardless of where your data comes from, our platform always validates data as it comes in. This means that sometimes not all the data from your Salesforce system will pass through our upload process (note that they have been pulled and flagged!). As a result, the number of total records may not match with what you expected to come from Salesforce.
To remedy this, you can do the following:
- Identify which fields are required or have specific validations (your Customer Success Manager can help).
- Ensure the values in Salesforce follow these validation rules, or find alternative fields.
The standard required fields and validations are;
- First Name: Required
- Last Name: Required
- Email: Required, and must be a valid email address
- Order Date: If provided, must be in "yyyy-mm-dd hh:mm:ss" or "yyyy-mm-dd" format, or Salesforce's standard
yyyy-MM-dd'T'HH:mm:ss.SSS'Z'.
While these are the standards, your CustomerGauge platform may be configured differently. Consult your Customer Success Manager to know how your system behaves.
My Formula field is not being pulled in
Even if your query works in the SOQL Workbench, it may not always work in the integration with CustomerGauge. Unfortunately, Formula fields are not supported in the Native Integration for Salesforce. We would recommend you to set up an alternative field, since Formula fields can not be resolved during pulls from CustomerGauge.
Certain fields return the value 'true' when they're blank
In Sandbox connections, Salesforce returns the value 'true' on the field types Email, Phone, Fax, Address, Text, Date, Datetime, if they're blank. We will store 'true' in CustomerGauge, as that is what Salesforce returns to us.
Element {}item invalid at this location
This error is seen if the WSDL file is not correct. For sandbox connections, you need to download and use the Partner_WSDL file and the Enterprise_WSDL for production environment. If there is a mismatch in type of environment and WSDL file, you will see the above error. Use the right WSDL to fix this.
Troubleshooting issues during Flagging
Flag attempt returns "insufficient access rights on object id"
If the flag attempt fails and has the message "insufficient access rights on object id", CustomerGauge reached out to Salesforce with the request to update a field. Salesforce declined this request because the user did not have the permissions to do the edit.
- Ensure that the user has access to edit the record, as well as related object records.
- Leads being converted appear to be more easily affected by this. Exclude converted leads from your Pull Query
Troubleshooting issues during Pushing
A date/datetime value is not pushed back in the correct format
If a date/datetime value gets passed to Salesforce in a "YYYY-MM-DD hh:mm:ss" format, opposed to "YYYY-MM-DDThh:mm:ssZ", that means we could not find the exact data type of the field you're attempting to push to.
- The push mapping is case-sensitive; please ensure that each field has the same capitalization as it shows in the API field names in Salesforce.
System.LimitException Apex CPU time limit exceeded
This can happen both during Flagging and Pushing - When a record gets updated or created in Salesforce, there could be lengthy custom processes that get triggered. When this happens, it's likely a custom Apex class or trigger that takes too long to finish. To resolve this, you'll need to involve your technical Salesforce team to optimise the Apex code.
An error occurs during Authentication, but Push is not activated
CustomerGauge connects to Salesforce for each integration, prior to checking whether Push is enabled for that integration. If you receive an Authentication error in the push process for an integration that has Push disabled, you can ignore that error.
You can help expanding this article!
We can't possibly find all the issues you might run into, but we try! If you run into an issue that is not covered in this article, please let us know so we can expand and help your peers in the future.