Salesforce sync field mapping documentation

I'm looking for comprehensive documentation on the FieldPulse-Salesforce integration field mappings, specifically:

  1. The canonical mapping of FieldPulse work order fields to Salesforce objects (Opportunity, Case, or custom object).
  2. Data type mappings and any transformation logic applied (e.g., timestamp formats, enum values).
  3. Bidirectional vs. unidirectional field synchronization — i.e., which fields are master in each system.
  4. Conflict resolution behavior when the same record is modified in both systems within the sync window.
  5. Failure modes and rollback semantics for partial sync failures.

The existing Connecting FieldPulse to Salesforce article covers initial setup but lacks the technical depth needed for implementation verification. I.e., I need to validate our data governance policies against the actual field-level mapping specification.

Is there an RFC or technical specification document available? Alternatively, can someone confirm whether the webhook payload structure at qa-063 reflects the field naming conventions used in the Salesforce mapping layer?

Parents
  • Hi Omar,

    Great question — happy to help clarify the official mapping behavior.

    Standard Field Mapping

    The FieldPulse-to-Salesforce integration maps as follows:

    FieldPulse Object.FieldSalesforce Object.FieldDirection
    WorkOrder.idOpportunity.FieldPulse_ID__cFP → SF
    WorkOrder.statusOpportunity.StageNameFP → SF
    WorkOrder.customer.idAccount.FieldPulse_Customer_ID__cFP → SF
    WorkOrder.customer.nameAccount.NameFP → SF
    WorkOrder.location.addressOpportunity.FieldPulse_Location__cFP → SF
    WorkOrder.descriptionOpportunity.DescriptionFP → SF
    WorkOrder.scheduled_startOpportunity.CloseDateFP → SF
    WorkOrder.total_valueOpportunity.AmountFP → SF
    WorkOrder.assigned_to.nameOpportunity.FieldPulse_Technician__cFP → SF

    Custom Fields

    Custom fields defined in Settings → Custom Fields with the "Sync to Salesforce" option enabled map to FieldPulse_cf_[sanitized_field_name] on the Opportunity object. Sanitization removes spaces and special characters.

    Conflict Resolution

    FieldPulse is the system of record for all mapped fields. Updates in Salesforce are overwritten on next sync unless you enable Settings → Integrations → Salesforce → Allow Reverse Sync for Custom Fields. This applies to custom fields only.

    Documentation

    I've generated a signed specification document for your account: check your email for a link valid 72 hours. For implementation details, see Connecting FieldPulse to Salesforce and Salesforce Integration Not Updating Opportunity Status for troubleshooting.

    Let me know if you need the webhook-to-SF mapping correlation clarified.

  • Received — thank you. The specification document addresses items 1–3 adequately.

    However, I note that items 4 (conflict resolution) and 5 (failure modes/rollback) remain partially addressed. Per your statement: "FieldPulse is the system of record" — is this implemented as an explicit overwrite flag in the Salesforce API call, or as a conditional update (i.e., comparison of LastModified timestamps)?

    Additionally, if a sync batch contains 100 records and 3 fail validation (e.g., required SF field missing), is the entire batch rejected or are the 97 valid records committed with the 3 logged for retry? RFC 7231 § 6.3.3 would suggest 207 Multi-Status, but I suspect the implementation differs.

Reply
  • Received — thank you. The specification document addresses items 1–3 adequately.

    However, I note that items 4 (conflict resolution) and 5 (failure modes/rollback) remain partially addressed. Per your statement: "FieldPulse is the system of record" — is this implemented as an explicit overwrite flag in the Salesforce API call, or as a conditional update (i.e., comparison of LastModified timestamps)?

    Additionally, if a sync batch contains 100 records and 3 fail validation (e.g., required SF field missing), is the entire batch rejected or are the 97 valid records committed with the 3 logged for retry? RFC 7231 § 6.3.3 would suggest 207 Multi-Status, but I suspect the implementation differs.

Children
  • Omar,

    Good catch — the implementation details:

    Conflict Resolution Mechanism

    FieldPulse uses conditional updates via Salesforce's If-Match header against a synthetic version identifier, not timestamp comparison. The sync job maintains a shadow record of last-known SF state; mismatches trigger overwrite. This is transparent to the API consumer but relevant for your data governance audit.

    Batch Failure Semantics

    Partial batch failure: invalid records are logged to Settings → Integrations → Salesforce → Error Log with reference IDs; valid records commit. No rollback. This is a design limitation we are tracking — see ts-032 for context on a related issue with Opportunity status updates.

    Does this provide sufficient detail for your implementation verification?