Integration guide
Salesforce and Procore integration
A Closed Won opportunity creates the Procore project, stamped with the Salesforce opportunity ID. Salesforce signals the change through a record-triggered Flow, a platform event or Change Data Capture; after setup, Procore owns delivery data.
System facts last verified October 2026 against the vendors' documentation (sources below). Confirm details with Salesforce and Procore Technologies before you build.
Salesforce and Procore side by side
- API style
- SalesforceREST, SOAP, Bulk API 2.0, Pub/Sub API and Streaming (CometD).
- ProcoreREST/JSON. Procore states that direct database access and RDBMS, XML or SOAP integrations aren't supported.
- Authentication
- SalesforceOAuth 2.0 through an External Client App; Salesforce says creating new connected apps is restricted as of Spring '26 and recommends External Client Apps instead.
- ProcoreOAuth 2.0, registered as an app in the Procore Developer Portal: authorization code (acts as a specific user) or client credentials through a Developer Managed Service Account (DMSA) with company and project permissions. Traditional service accounts were sunset on March 18, 2025.
- Webhooks / events
- SalesforceEvent-based: Change Data Capture and platform events delivered through the Pub/Sub API or CometD, retained for three days. Outbound HTTP calls are usually built with Flow.
- ProcoreYes. Company- or project-level create, update and delete triggers; Procore recommends payload v4.0 for new integrations. Delivery is best-effort with retries, and events are discarded after 12 hours of continuous failure, so pair webhooks with a periodic reconciliation sync.
- Rate limits
- SalesforceOrg-wide API calls per rolling 24 hours: 15,000 on Developer Edition; Enterprise starts at 100,000 plus per-license allocations. 25 concurrent long-running requests in production. CDC delivery allocations vary by edition.
- ProcoreAn hourly (60-minute) limit and a 10-second spike limit, reported in X-Rate-Limit-Limit, -Remaining and -Reset headers; exceeding either returns 429, and 503 with Retry-After signals platform load. Procore publishes no fixed default: its rate-limiting page uses sample headers (600 per hour, 25 per spike window), warns not to assume a fixed window such as 3,600/hour, says values can change, and lets apps request an increase. Every request counts, including failed ones.
- Sandbox
- SalesforceYes. Free Developer Edition orgs; paid orgs also have sandboxes and scratch orgs.
- ProcoreYes. A developer sandbox with seed data is created when you register an app (you can have many). Customers can also enable on-demand and monthly sandboxes; the monthly one is refreshed from production each month. Not available to Federal Zone customers.
- Exports and files
- SalesforceBulk API 2.0 query jobs for large extracts.
- ProcoreNo bulk export API confirmed; reporting integrations page through list endpoints. Procore Analytics is a separate product.
- Marketplace / partners
- SalesforceAppExchange. Not confirmed (partner program page not checked).
- ProcoreProcore App Marketplace and the Procore Technology Partner Program (application, technical review, certification, agreement, listing).
Who owns what
- One direction at project start: a won deal creates the project, stamped with the CRM deal ID.
- After setup, the project system owns delivery data; push status back to the CRM only if sales needs it.
What syncs between Salesforce and Procore
The typical shape for this pair. Every row is typical: confirm it against your configuration in discovery.
| Object | Direction | System of record | |
|---|---|---|---|
| Closed Won opportunity → project | Salesforce to Procore | Salesforce until won; Procore after | On stage change (Flow, platform event or CDC) |
| Typical frequency: On stage change (Flow, platform event or CDC). Notes: Trigger on one stage value and write it down. Events are retained for three days, so a consumer that was down can replay what it missed.(Typical: confirm against your configuration.) | |||
| Accounts → directory / owner | Salesforce to Procore | Salesforce | On opportunity won |
| Typical frequency: On opportunity won. Notes: Look for an existing Procore directory company before creating one; store the Procore ID on the account.(Typical: confirm against your configuration.) | |||
| Contacts | Salesforce to Procore | Salesforce | On opportunity won |
| Typical frequency: On opportunity won. Notes: Only the contacts the project team needs.(Typical: confirm against your configuration.) | |||
| Opportunity ID ↔ project ID | both ways | Both, written once | At project creation |
| Typical frequency: At project creation. Notes: Write the opportunity ID onto the Procore project and the project ID back to the opportunity, so reporting joins pipeline to delivery on IDs.(Typical: confirm against your configuration.) | |||
| Amount / contract value | Salesforce to Procore | Salesforce for reference; Procore prime contract after award | On opportunity won |
| Typical frequency: On opportunity won. Notes: Reference value only; the prime contract in Procore becomes the record.(Typical: confirm against your configuration.) | |||
| Project status | Procore to Salesforce | Procore | Daily, optional |
| Typical frequency: Daily, optional. Notes: Only if sales needs it, as a field on the opportunity or account. Every write counts against the org's 24-hour API limit.(Typical: confirm against your configuration.) | |||
Directions, owners and frequencies are the typical pattern from our integration guides and mapping workbook. Confirm each one against your configuration in discovery.
Is a native connector enough?
We haven't confirmed a documented native connector for this pair. Check Salesforce AppExchange and the Procore App Marketplace for a partner connector first: if one moves the records you need with your cost structure and approvals, configure it. Build when the mapping needs governing, when failures need routing to a person, or when you also need cross-system reporting.
Compare native connectors with a custom buildCommon gotchas
- Create an External Client App for the integration. Salesforce restricts creating new connected apps as of Spring '26.
- The Salesforce API limit is org-wide over a rolling 24 hours, and installed packages count against it. Status write-back and backfills share it with everything else in the org.
- Change Data Capture covers only five selected entities by default without the add-on; confirm Opportunity is one of them before designing around CDC.
- On the Procore side, use a Developer Managed Service Account for company-level project creation, and read the rate-limit headers rather than assuming a fixed hourly number.
Sources
- Salesforce REST API Developer Guide
- Salesforce Developer Limits and Allocations Quick Reference
- Salesforce Change Data Capture Developer Guide
- Procore developer documentation
- Procore: choosing an OAuth grant type
- Procore: rate limiting
- Procore: webhooks
- Procore: development environments
- Procore: financial tools tutorial
- Procore: partner program overview
Frequently asked questions
How does a Closed Won opportunity create a Procore project?
A record-triggered Flow, a platform event or Change Data Capture signals the change. The integration creates the Procore project through the Procore API and writes the project ID back to the opportunity.
Which Salesforce app type should the integration use?
An External Client App. Salesforce restricts creating new connected apps as of Spring '26 and recommends External Client Apps for new integrations.
Does a Salesforce and Procore sync use much of the API limit?
Usually not for the hand-off itself: a handful of calls per won opportunity. Backfills and status write-back are what eat into the org-wide 24-hour limit, which installed packages share.
Next step
Connecting Salesforce and Procore?
Bring one real job and the records you want to move. We'll walk through what syncs, who owns each record, and what to check first.