This article covers a validation error that Salesforce can return when you deploy a custom Report Type built on Campaigns and Campaign Members. It explains the two known causes of the error, how to tell which one applies to you, and how to fix each one.
Error overview
When validating or deploying a Report Type metadata component, Salesforce returns an error that appears in our app as on screenshot below:
Could not find field <id> in table CampaignMember-ContactOrLead
You may run into this error when validating your package via Compare and deploy (e.g. an org to org validation), or when validating a PR in your Gearset Pipeline.
The field ID changes from case to case, but the table is always CampaignMember-ContactOrLead.
Causes of the error
There are two known causes. The first is the most common one we see, and it appears to be a Salesforce issue, rather than a permissions related problem.
Cause 1 - A Campaign Member field shares its API name with a Lead or Contact field
This happens when your Report Type includes a Campaign Member custom field as a column, and the Lead or Contact object also has a custom field with the same API name.
When you add a Campaign Member field to a Report Type layout, Salesforce saves the column using only the field's API name. For example:
<field>Source_ID__c</field>
<table>Campaign.CampaignMembers</table>
When a new or changed Report Type is deployed, Salesforce matches that name to the Lead or Contact field first, instead of the Campaign Member field, and the deployment fails. That's why the ID in the error belongs to a Lead or Contact field in the target org, rather than the field you added to the Report Type.
A few things follow from this:
The Report Type usually works in the org where it was built, because the error only occurs on deployments of new or changed Report Types.
Adding the column manually in the Salesforce UI works. The issue only occurs when the Report Type is deployed through the Metadata API.
Field-Level Security (FLS) can be correct for every user and the error still occurs.
Gearset deploys the Report Type XML exactly as Salesforce provides it.
Note: We have reproduced this behaviour in an on-demand scratch Salesforce org and found no form of the column that Salesforce accepts, so this can't be worked around in the deployment package.
Cause 2 - The deploying user doesn't have access to the field
Salesforce documents one cause for this error: the Salesforce user performing the deployment doesn't have Field-Level Security (FLS) access to the field referenced in the error message.
Identify which cause applies
Log in to the target org of the failed deployment (not the source org). Field IDs are specific to each org.
In your browser's address bar, replace everything after
.com/with the field ID from the error message, then press Enter.Note the field's object (Lead or Contact) and its API name.
In your source org, go to Setup > Object Manager > Campaign Member > Fields & Relationships, and check whether Campaign Member has a custom field with the same API name.
Check whether that Campaign Member field is a column in the failing Report Type.
If Campaign Member has a field with the same API name and it's used in the Report Type, you're hitting Cause 1. Follow Fixes for Cause 1.
If there's no matching Campaign Member field, follow Fixes for Cause 2.
Fixes for Cause 1
There are two options. Option 1 is quicker and doesn't change your data model. Option 2 is a permanent fix, but needs more planning.
Option 1 - Deploy without the column and add it back in the target org
This is the option we recommend if you need to unblock a release or promote a PR to the next environment.
In your source (org or branch), remove the affected Campaign Member field from the Report Type. In Salesforce, go to Setup > Report Types, open the Report Type, click Edit Layout, and remove the field. Then commit the updated Report Type to your feature branch.
Validate and deploy as normal. The rest of the Report Type and the rest of the PR's changes can go through.
After a successful deployment, add the field back to the Report Type layout manually in the target org.
Record this as a post-deployment step, so it's repeated in each Pipeline environment the Report Type is deployed to.
This means the Report Type in your orgs will include a column that isn't in source control. If you later commit the Report Type with the column back in, the next deployment of a changed version will fail again, so keep the column out of your branches while the field names match.
Option 2 - Rename the Campaign Member field's API name
Changing the Campaign Member field's API name so it no longer matches the Lead and Contact fields removes the cause, and the Report Type should validate and deploy without throwing this error.
Before you do this, check where the field is used. Renaming a field's API name affects anything that references it, such as Reports, Flows, Apex, formulas, and integrations. Use Where is this used? on the field in Setup to find references.
Also, plan how the rename will reach each org. Deploying a field under a new API name creates a new field rather than renaming the existing one, and data in the old field isn't moved across. Depending on your process, you may need to rename the field in each org, or create the new field, migrate its data, and then remove the old one.
Note: Before you proceed with this route, read through our documentation on how to handle API rename of a Salesforce component through the Pipeline.
Fixes for Cause 2
Step 1 - Confirm which Salesforce user runs the deployment
Salesforce checks field access for the user that the org connection in Gearset is authenticated as, not for the Gearset user who run PR validation (e.g. in Gearset Pipeline). This is the most common reason FLS checks pass but the error persists.
If you're deploying via Compare and deploy, it's the Salesforce user on the target org connection.
For user-owned CI jobs and Gearset Pipeline, it's the user on the connection for the target environment.
For team-shared pipelines, many teams use a dedicated integration or service user to run their pipeline validations/deployments, and that user can have different permissions from the other people (Salesforce users) on the team.
Step 2 - Check Field-Level Security for the deployment user
In the target org, check that the deploying user can see the field:
Go to Setup > Users, open the deploying user, and click View Field Accessibility.
Select the object the field belongs to and check that the field is Visible.
If it isn't, grant Visible access through the user's profile or a permission set assigned to them.
A few things to keep in mind:
A System Admin profile doesn't automatically have visibility of every custom field. Check the field itself rather than assuming.
Formula fields still need the Visible checkbox ticked for each profile or permission set assigned to the deploying user.
Because the column sits in the Lead or Contact section, check the field on both Lead and Contact.
Once access is granted, retry the validation in Gearset.
Step 3 - Validate as a different user to confirm
If you're not sure whether access is the problem, run a Compare and deploy validation of the same Report Type from the same source (org or branch) to the same target org, using a target org connection authenticated as a different Salesforce user who has confirmed access to the field.
If the validation passes as the other user, the original deploying user's access is the problem. Return to Step 2 and compare the two users' profiles and permission sets.
If it fails for both users, go back to Identify which cause applies and check for a matching Campaign Member field again.
Contacting support
If none of the steps above help you resolve the error, feel free to contact our support team through the in-app chat and include:
The full error message, including the field ID.
The field's API name, object and data type, from the "Identify the field" step.
The username of the deploying Salesforce user, and confirmation that you've checked FLS for that user on both Lead and Contact objects.
Information on whether you're deploying directly (org to org), or via your Gearset Pipeline.
A shared link to the comparison used to validate your deployment (PR).
This helps us investigate without asking you to repeat checks.
Helpful resources
For more information on a root cause of the issue that has been confirmed by Salesforce, check their Knowledge Article:
deploying ReportType Using Salesforce Metadata API Fails with "Could Not Find Field" Error (published on 19 Jun 2026).
Disclaimer: This error is returned by Salesforce directly, rather than Gearset. Even so, we offer guidance based on our combined experience with the Metadata API. Where possible, we try to help guide you to fix or avoid this error. In the case that this isn't possible, we may need to direct you to Salesforce support for further clarification.