Salesforce

If your sales team lives in Salesforce, this adapter keeps your campground guests visible there. Every guest profile becomes a Contact; every booking becomes an Opportunity. Edits flow both ways, with conflicts logged but not crashed.

What it gives you

• Bidirectional sync: CampOne → Salesforce (push on save) and Salesforce → CampOne (hourly pull)
• Idempotent on email (Contacts) and booking reference (Opportunities)
• Configurable field mapping per object — you decide which CampOne field maps to which Salesforce field
• Conflict logging: when both sides edited the same field since last sync, last-write-wins, but the conflict is recorded for audit
• OAuth refresh-token flow — the access token refreshes itself; the long-lived refresh token sits encrypted in CampOne

Prerequisites

Salesforce is self-service for development:

1. Sign up for a free Developer Edition org at https://developer.salesforce.com/signup (any unique username works — try you+sf-dev@yourdomain.com).
2. In your dev org, go to Setup → External Client App Manager and create a new External Client App with OAuth scopes api and refresh_token.
3. Note the Client ID (Consumer Key) and Client Secret from the External Client App.

For production, your customer (or you, on their behalf) does the same in their production Salesforce org.

Important: Salesforce now blocks legacy “Connected Apps” by default. New integrations should use External Client Apps (ECAs) — that’s what Step 2 above creates.

What you’ll paste into CampOne

Settings → Integrations → Vendor Adapters → Salesforce:

Field	Description
Environment	Sandbox (developer / sandbox org) or Production
Instance URL	e.g. https://yourcompany--sandbox.my.salesforce.com
Client ID	Consumer Key from the ECA
Client Secret	Consumer Secret from the ECA
Object mapping	JSON object — defaults are sensible; override per field

Click Save, then Connect via OAuth. CampOne sends you to Salesforce’s authorisation page; on return, the refresh token lands in CampOne and the connection goes green.

Field mapping defaults

Out of the box:

{
  "guest_to_contact": {
    "first_name": "FirstName",
    "last_name": "LastName",
    "email": "Email",
    "phone": "Phone",
    "city": "MailingCity"
  },
  "booking_to_opportunity": {
    "booking_reference": "Name",
    "total_price": "Amount",
    "check_in_date": "CloseDate",
    "status": "StageName"
  }
}

Edit the JSON in the settings card to match your custom fields.

What runs when

• On guest save in CampOne → push Contact (immediate).
• On booking save in CampOne → push Opportunity (immediate).
• Every hour → pull changes from Salesforce, apply per-field, log conflicts.

Conflict handling

If both sides edited the same field between syncs, the most recent write wins. The integration log records the conflicting field and the value we kept, so a manual reconcile is fast.

Support contacts

• Salesforce community / Q&A: https://trailhead.salesforce.com/trailblazer-community
• REST API + Connected Apps documentation: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_oauth_and_connected_apps.htm

Limitations

• Real-time push from Salesforce (Streaming API / Change Data Capture) is a roadmap item; today the pull runs hourly.
• Salesforce Outbound Messages (SOAP) are not wired — the streaming approach above will replace them when implemented.
• The free Developer Edition has API call limits. For high-volume sites, ask your customer to run the integration on their production org or a Performance/Unlimited sandbox.