Salesforce integration: mapping work orders to Opportunities

Question

I am configuring the FieldPulse to Salesforce integration for our organization. I need to establish a bidirectional mapping between FieldPulse work orders and Salesforce Opportunities. However, I am encountering difficulties with the field mapping configuration screen.

Current Environment: 
 
 FieldPulse account: Production, API version v1 
 Salesforce edition: Enterprise 
 Integration status: Connected, OAuth authorized

Specific Issues: 
 
 The field mapping interface does not display all standard Opportunity fields (e.g., "StageName", "CloseDate", "Amount") 
 Custom fields created in FieldPulse do not appear in the mapping dropdown 
 The documentation indicates bidirectional sync is supported, but I cannot locate the configuration toggle for sync direction

Questions: 
 
 Is there a required field configuration in Salesforce that must be completed before FieldPulse can enumerate available Opportunity fields? 
 Are there specific Salesforce API permissions required beyond the standard OAuth scopes? 
 What is the expected latency for bidirectional updates — i.e., if a work order status changes in FieldPulse, what is the SLA for the corresponding Opportunity update in Salesforce?

I have confirmed that the connected Salesforce user has System Administrator profile and that API access is enabled. I can reproduce this behavior consistently across multiple browser sessions. I have reviewed the Salesforce integration guide but it does not address these specific configuration scenarios.

Ticket reference: FP-INT-2847 (opened with support 48 hours ago, awaiting escalation).

Eli Torres (Staff) · Accepted Answer

Hey Anita — yeah, this one trips people up more than it should. The mapping screen only shows fields that are both readable and writable by the connected Salesforce user, and that exist on the Opportunity object layout that's active for that user. System Admin profile should cover it, but I've seen cases where field-level security or record types are filtering things out.

Quick diagnostic — can you run this in your Salesforce Developer Console?

SELECT DeveloperName, Label, IsUpdateable, IsCreateable 
FROM FieldDefinition 
WHERE EntityDefinition.QualifiedApiName = 'Opportunity'

Check if IsUpdateable is false on the fields you're missing. Also worth verifying: does the connected user have access to the Opportunity record type that's default for the integration?

Re: custom fields — those need to be marked as "External ID" or at least "Visible" in FieldPulse, and they need API names that don't collide with Salesforce reserved words. There's a known quirk where fields with underscores at the start or double underscores anywhere get filtered out.

On bidirectional sync: the toggle is buried. Go to Settings → Integrations → Salesforce → Advanced and look for "Sync Direction" — it's a radio group, not a toggle, which is why people miss it. Options are Push to Salesforce, Pull from Salesforce, or Bidirectional.

Latency: typically 30–60 seconds for work order → Opportunity, 2–5 minutes the other way (Salesforce → FieldPulse polls on a slower interval). We don't publish hard SLAs for the integration layer but I can tell you the webhook path is much faster than the polling path.

Want me to look at your specific field list? If you DM me the org ID I can check what the schema discovery is returning.

Devon Marsh · Answer

Heads up on the bidirectional piece — we've been running this in prod for about 6 months and found some edge cases.

The "Bidirectional" setting is optimistic, i.e., last-write-wins with no conflict resolution. If you have automation in Salesforce (Process Builder, Flows) that touches Opportunities, you'll get race conditions. We ended up going Push-to-Salesforce only and using a custom Apex trigger to push changes back to FieldPulse via webhook when we actually need it.

Also worth noting: the Amount field mapping is string-to-number conversion, so if you have any formatting in FieldPulse (currency symbols, commas) it'll fail silent and write null. We pre-process in a middleware layer now.

YMMV but bidirectional sounds good on paper and was more headache than it was worth for us.