Salesforce custom fields not appearing in mapping screen

I have completed the initial configuration of the Salesforce integration per the documentation. The connection is established and standard objects (Account, Contact, Opportunity) are visible in the FieldPulse mapping interface. However, I have confirmed that custom fields created in Salesforce are not appearing as available fields for mapping.

Specifically, I have verified the following:

  1. The custom fields are created on the Opportunity object in Salesforce.
  2. The API names are properly formatted (using __c suffix as expected).
  3. The FieldPulse integration user has read access to these fields via the assigned Profile and Permission Sets.
  4. The fields are populated with data in at least one existing Opportunity record.
  5. I have attempted to refresh the field list in the FieldPulse mapping screen using the "Refresh Fields" button located at the bottom of the mapping table.

The Salesforce organization is running API version 59.0. FieldPulse account is on the Enterprise tier.

Is there a known limitation regarding which field types are exposed, or is there a synchronization delay I should account for? I have waited approximately 45 minutes since field creation in case caching is involved.

Reference: Configuration performed per Connecting FieldPulse to Salesforce.

  • Check field-level security for the integration user. API visibility ≠ mapping visibility.

    • Setup → Object Manager → Opportunity → Fields & Relationships
    • Edit each custom field → Set Field-Level Security
    • Verify "Visible" is checked for the Profile assigned to your integration user

    Also: formula fields and encrypted fields do not appear in the mapping UI.

  • Thank you for the response. I have confirmed that Field-Level Security is configured correctly — the integration user's Profile has "Visible" enabled for all custom fields in question. None are formula or encrypted fields. They are standard text, number, and picklist field types.

    I have also verified that the integration user can retrieve these fields via direct SOQL query through the Salesforce Developer Console, which suggests the API permissions are functioning correctly at the Salesforce layer.

    Is there a specific API version requirement or metadata refresh interval on the FieldPulse side that I may have missed in the documentation?

  • Hey Anita — Leo's absolutely right about field-level security being the usual culprit, but since you've confirmed that's set up properly, let me dig into what's happening here.

    The mapping screen pulls from a cached metadata snapshot that's refreshed when you hit "Refresh Fields," but there's a quirk: we only surface custom fields that have at least one record with a non-null value in your Salesforce org. This is an optimization to keep the mapping UI from being overwhelmed with unused legacy fields, but I realize it's not documented as clearly as it should be.

    Can you confirm:

    1. Do these custom fields have values in Opportunity records that were created or updated after the integration was initially connected? We sample a window of recent records.
    2. Are any of the fields on Opportunities that are owned by the integration user itself, or only on records owned by others?

    If the fields are populated but still not appearing, I can trigger a manual metadata refresh on our side. Also worth noting: we're rolling out an update in the next two weeks that removes this sampling restriction entirely — all readable fields will appear regardless of data presence.

    In the meantime, if you need an immediate workaround, creating a test Opportunity with values in all the custom fields and then clicking "Refresh Fields" again should surface them.

    Let me know what you find and I can escalate if needed.

  • Heads up — I ran into this exact thing last month. The workaround Eli mentioned works, but YMMV depending on how your org handles record visibility.

    In my case, the fields were on Opportunities owned by users in a different Role hierarchy that the integration user couldn't see via sharing rules, even with "View All" on the object. The SOQL worked in Dev Console because I was running as myself, not as the integration user.

    Worth doing an EXECUTE AS check:

    System.runAs(integrationUser) {
        List<Opportunity> recent = [SELECT Custom_Field__c FROM Opportunity LIMIT 1];
    }

    If that throws no rows or null values, the visibility issue is at the record level, not field level.

    Also — the upcoming update Eli mentioned is tracked in API v2.1 Now Available with Webhook Improvements (scroll to "Salesforce Metadata Handling"), though it doesn't mention the sampling removal yet.

  • Thank you both. I have identified the root cause.

    Following Devon's suggestion, I executed a query as the integration user and confirmed that the custom fields are indeed visible. However, I then examined the Opportunity records more closely and determined that the custom fields were created recently and the existing Opportunities had not yet been backfilled with data.

    After populating a test Opportunity record with values in all custom fields and clicking "Refresh Fields" in FieldPulse, the fields now appear correctly in the mapping interface.

    From a governance perspective, it is worth noting that this behavior creates a dependency on data presence that may not be intuitive for administrators configuring the integration. I would recommend updating the documentation to clarify this requirement, or preferably, removing the sampling limitation as indicated in the upcoming release.

    I will proceed with field mapping configuration. Thank you for the assistance.

  • Glad we got you unblocked, Anita — and thank you for the detailed follow-up. You're absolutely right that this behavior is under-documented; I'm flagging this with our docs team to get the "data presence" requirement added to Connecting FieldPulse to Salesforce this week.

    I've also linked your feedback to the internal ticket for the sampling removal (FP-7821) as additional confirmation that we should prioritize the broader field visibility change.

    I'll circle back here once that ships. If you hit any other issues with the mapping itself, feel free to @ me directly.