Salesforce integration: bidirectional or push-only?

I have reviewed the documentation at Connecting FieldPulse to Salesforce, but I require clarification regarding the data flow directionality in the integration architecture.

Specifically, I need to understand:

  1. Does the FieldPulse-to-Salesforce integration push data from FieldPulse to Salesforce only?
  2. Or does Salesforce push updates back to FieldPulse (e.g., Opportunity stage changes updating Work Order status)?
  3. If bidirectional, what is the conflict resolution mechanism when the same record is modified in both systems?
  4. What are the supported sync frequencies and whether near-real-time or batch?

From a governance perspective, I need to document the authoritative source of truth for each entity type before provisioning this integration in our production environment. I have confirmed that we are running Salesforce Enterprise Edition with API access enabled, and our FieldPulse account is on the Professional tier.

Any clarification or pointer to a technical specification document would be appreciated.

  • Hey Anita — I just went through this myself last quarter. It's mostly unidirectional FieldPulse → Salesforce, with one exception.

    Here's what actually happens:

    • Work Orders → Opportunities (create or update)
    • Customers → Accounts/Contacts
    • Technicians → Users (optional, we skipped this)
    • Invoices → Opportunity Products (if you have that enabled)

    The "exception" is that Opportunity stage changes can trigger a status update back to FieldPulse, but only if you explicitly enable it in the integration settings. It's not on by default. Heads up: when we first turned that on, we saw some race conditions where a dispatcher updating a WO and a rep updating an Opportunity at the same time caused weird flapping. We ended up turning it off and just using FieldPulse as the source of truth for status.

    YMMV, but worth testing in a sandbox first. The sync is near-real-time via webhook, not batched, which is nice.

  • Hey Anita! Devon's got the right shape of it — let me give you the official line here.

    The FieldPulse-Salesforce integration is unidirectional by default: FieldPulse is the source of truth, and we push to Salesforce. The bidirectional piece Devon mentioned is called "Opportunity Sync Back" and yeah, it's opt-in only. When enabled, we do a best-effort merge, but I won't sugarcoat it: there's no fancy conflict resolution. Last-write-wins based on timestamp, which... yeah, can get messy in practice.

    Here's the entity mapping for your governance docs:

    FieldPulse          → Salesforce          Direction      Sync Type
    ─────────────────────────────────────────────────────────────────────────
    Work Order          → Opportunity           Push (FP→SF)   Real-time webhook
    Customer            → Account               Push (FP→SF)   Real-time webhook
    Customer Contact    → Contact               Push (FP→SF)   Real-time webhook
    Invoice             → Opportunity Product   Push (FP→SF)   Real-time webhook
    Opportunity Stage   → Work Order Status     Pull (SF→FP)   Configurable, 5-min poll

    We don't currently support Salesforce-initiated creates (e.g., creating a Work Order from an Opportunity). That's on the roadmap but no committed timeline.

    For your use case, I'd recommend keeping it one-way and using a custom Salesforce flow if you need to react to Opportunity changes, rather than enabling the sync-back. More control, fewer surprises.

    Full spec is in the integration guide — I can also grab you the webhook event schema if you need it for your security review.

  • Eli, thank you for the detailed mapping. This confirms my understanding.

    Two follow-up questions:

    1. Is the webhook delivery guaranteed at-least-once, and what is the retry policy for failed deliveries?
    2. For the "Opportunity Sync Back" feature, can the polling interval be configured, or is 5 minutes fixed?

    I will proceed with unidirectional configuration per your recommendation. The webhook event schema would be useful for our security documentation — please share when convenient.

  • Happy to help!

    1. Webhook delivery: At-least-once, yes. Retry policy is exponential backoff: 5s, 25s, 125s, then dead-letter after 3 attempts. You can replay from the integration settings panel or via API if you need to.

    2. Polling interval: Fixed at 5 minutes, not configurable currently. There's an internal ticket to make this adjustable but it's not prioritized.

    I'll DM you the webhook schema — it's a bit long to paste here and has some internal field references I should annotate for you.

  • From a governance perspective, it is worth noting that the "last-write-wins" conflict resolution mentioned above may present compliance implications under SOC 2 Type II audit criteria if financial data is involved.

    We have elected to implement a middleware layer that logs all cross-system mutations with timestamps and user attribution, creating an immutable audit trail. This is not strictly required, but from a risk management standpoint, it provides defensible evidence of data lineage should discrepancies arise.

    Additionally, I would recommend reviewing whether your Salesforce field-level security settings align with the API user's permissions — we identified a case where the integration user could read fields that were restricted in the UI, which created an access control gap.