Salesforce integration: mapping work orders to Opportunities

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.

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.

Hi Anita! Happy to help clarify a couple things from the support side.

Eli covered the field visibility piece well — one additional thing to check is whether your Opportunity object has Field History Tracking enabled for the fields you want to map. It's not strictly required, but the integration uses the History API for some conflict detection in bidirectional mode, and without it you may see stale data.

Re: your ticket FP-INT-2847 — I see this is currently with Tier 2. The escalation you requested is in progress, but in the meantime, I'd recommend trying Eli's diagnostic query. If you can share the output (sanitized), we can confirm whether this is a permissions issue or a schema discovery bug that's been flagged for the next release.

Also linking this known issue — if you're on Salesforce API v59.0 or higher, there's a regression affecting custom field enumeration. We're targeting a fix in the July maintenance window.

Thank you for this insight. I have confirmed that we have multiple Flows triggered on Opportunity update. From a governance perspective, this is concerning.

Does your middleware approach use the FieldPulse outbound webhook, or did you implement a polling mechanism? I need to understand the failure modes if the webhook delivery fails.

We use the outbound webhook — work_order.status_changed and work_order.updated. FieldPulse retries 3 times with exponential backoff (roughly 30s, 2min, 5min) then gives up. We queue failed deliveries in SQS and alert if the DLQ builds up.

One gotcha: the webhook payload doesn't include the full Salesforce Opportunity ID, just the FieldPulse work order ID. We maintain a lookup table in DynamoDB that maps them, populated from the initial push. Worth building that in from the start.

I would like to expand on the latency question, as there are additional variables to consider.

The documented 30–60 second propagation time for FieldPulse → Salesforce assumes the integration user's API quota has not been exhausted. Salesforce imposes a rolling 24-hour limit on API calls per license type; Enterprise Edition provides 1,000 calls per user per day, with the ability to purchase additional calls.

Given that each work order sync consumes 2–4 API calls (read existing record, write updates, potentially query for related objects), high-volume operations may trigger rate limiting. The FieldPulse integration does not currently implement token bucket or leaky bucket throttling — it will queue and retry, but the retry interval is not configurable and may exceed your SLA requirements.

From a spec compliance perspective, I.e., if you require sub-60-second sync with high probability, I would recommend implementing your own queuing layer with exponential backoff and dead letter handling, rather than relying on the native integration.

Additionally: has anyone verified whether the webhook signature verification uses HMAC-SHA256 with a constant-time comparison? I have not inspected the implementation, but this would be a prerequisite for using the webhook path in a security-sensitive deployment.