Salesforce Integration - Remove Custom Fields


Q: What feature / functionality are you looking for?
A: I don’t want Unbounce to create the “Submitter IP” or “Source” Lead custom fields.

Q: What problem are you trying to solve?
A: I already have enough custom fields and each of the fields I create adhere to a certain naming convention. These are dupes of things I already have and each time I delete them they come back into my org. I’ve tested this and it appears to be due to the Unbounce integration.

Q: If solved, what value would this provide (ex. increased efficiency, cost savings, etc.)?
A: This would help to keep my org clean of fields I don’t want or need.

Q: Use Case example? (ex. As a ____ I want to be able to _____ so I can _____.)
A: I want to have only fields that I use and that I’ve created for a given purpose. These fields serve no purpose.

Q: Is this being solved by another workaround or any other tool today?
A: This is specifically caused by the Unbounce integration, so “No”.


I realized in my screenshot I included the SubmitterIP in edit mode. Here is a different screenshot that shows that each field was created at exactly the same time.

When I try to remove the fields, they get automatically recreated when the Integration fires. Since we already have fields for this in our org, it’s nice to use existing multi-use fields, and for the fields that are specific to Unbounce I can prefix them with “Unbounce_”. This way a generic field like “Source__c” doesn’t confuse myself or other users/admins when creating…

  1. System Reports
  2. Mail Merges
  3. Field Validations
  4. Anything else involving fields in the system


I haven’t set this up before, but you may be able to use Zapier to replace the standard integration – normally it’s possible to choose which fields/data is sent.

Might be a good short-term fix :slight_smile:


Zoe, thanks for the suggestion. Overall, I’m quite happy with the Unbounce to Salesforce integration. Having seen a number of integrations with Salesforce I’d rate it a “Good” and close to a “Very Good”. It took a little while to learn how to map things effectively and efficiently but overall…

  1. It works
  2. It’s fairly easy to setup
  3. It’s effective in what it intends to do

So in that regard, I’m a bit hesitant to switch to anything else as I recognize that no integration between two different systems is perfect. However, because it’s just a couple of small annoyances away from being “Very Good” or perhaps even “Excellent”, I figured I’d mention a feature request here to see if it gets any traction. As a coder myself at times I know that not all feature requests and changes take the same amount of time, so I thought, “Why not send it?”


Totally understand that! :slight_smile:


Hey @pelowski,

While I wouldn’t consider it “fixed” by any stretch, we’ve changed this behaviour a little bit recently. Those custom fields should only get created when you configure/re-configure your Salesforce integration (not on every lead delivery to Salesforce). Unfortunately, this means that even when you re-configure your field map, those extra fields are going to come back.

The workaround - your milage may vary - is to un-map those extra fields first and then go into Salesforce to remove them.

Ultimately, I think the proper way to address this is to give users the ability to select which custom fields they want to be created on the Salesforce side. I’m going to file ticket to see if we can get that addressed.



@hoyan.leung, thank you for the update! It’s good to know that it’s on your radar. After reading your message I considered trying to delete the fields from my org, (they’re not mapped to anything currently as I already have fields that function in these ways) but I’m at this point I’m choosing not to because I’ve already got a description associated with each telling me not to use them. If the fields suddenly reappear later on (with no description/context) after a new or updated Unbounce field remapping I’m worried I’m going to look at them and once again forget why they exist.

I definitely prefer your “properly solution” but another possible option (if I can be so bold as to suggest one) that would be great would be to allow us to specify the API names if/when Unbounce needs to create custom fields in Salesforce. One thing that makes these fields particularly irksome to me is that there is nothing that identifies that they were created by Unbounce. If they weren’t named so generically and were prefixed with “Unbounce_” in the API Name or something it would be more obvious, but I can’t tell you how many times I’ve gone to query the Leads table in the past year and thought “What is this Source custom field?” only to go back into the field definitions to remind myself that it’s an Unbounce field I don’t want to use.

I’ve also considered removing permissions for these two fields from all profiles but I’m worried that might break something with the Unbounce integration so I’ve never done it.

Thanks again for the update.