Salesforce Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for Salesforce connectivity. This package is a thin, MIT-licensed wrapper around the Salesforce REST API (auth, simple CRUD/SOQL). Its footprint suggests the integration layer is not inherently large — which sharpens the build-vs-buy question rather than answering it. The evidence here (11 stars, 0 dependents, no release since Nov 2020) points away from adopting this repo and toward either a maintained client or a small in-house wrapper.
• Roadmap gating for CRM sync. If lead/contact/opportunity sync, quote-to-cash, or service-case mirroring is on the roadmap, this is a signal that Salesforce integration is a capability we need — not that this is the vehicle. Use it to justify a scoped discovery spike.
• Feature scoping for a v1 integration. A bundle of this shape typically covers OAuth token handling, config-driven credentials, and basic object/SOQL operations. That's a reasonable v1 boundary; it deliberately does not cover Bulk API 2.0, Platform Events, Change Data Capture, or Composite/Batch semantics — plan those as later phases.
• Framework/stack decision input. This is a Symfony bundle, not a Laravel package. Adopting it inside a Laravel app means bridging the Symfony service container, config tree, and event dispatcher — a real hidden cost that should be priced into any "just use the library" estimate.
• Maintenance-risk budgeting. With no releases in over four years and zero dependents, any adoption implies we own the code. That converts a "free" dependency into a maintenance line item and should be reflected in the estimate.
• Reference architecture. Even if we don't adopt it, reading the source is a cheap way to size a thin client: token refresh, exception mapping, retry/backoff, and config surface are exactly the decisions we'd otherwise re-derive.

When to Consider This Package

Consider it only when:

• The consuming application is Symfony (or we're willing to vendor/fork it), not Laravel.
• The integration is genuinely narrow — read/write on a handful of standard objects, low volume, no real-time requirements.
• We are evaluating it as a fork candidate or reference implementation, with an explicit owner and a plan to pin the version and absorb security patching.
• We need a quick prototype to validate data mapping and field semantics before committing to a permanent client.

Look elsewhere when:

• You need Bulk API, Platform Events, Pub/Sub, CDC, Composite API, or modern OAuth flows (JWT bearer, client credentials) — coverage here is almost certainly absent or dated.
• You require PHP 8.x support, PSR-18/PSR-17 HTTP abstraction, or compatibility with current Laravel HTTP client and config conventions.
• Customer data or compliance scope is involved: an unmaintained dependency in the CRM path is a security-review blocker regardless of MIT licensing.
• You'd be the first dependent (0 today) — no ecosystem signal, no community answers, no upstream fixes.
• You need vendor support or an SLA; there is none.

Recommended motion: a 1–2 day spike — read the source, attempt the four or five calls we actually need, and compare against maintained alternatives and a ~1–2 week in-house thin client. Set an explicit decision checkpoint before any code lands.

How to Pitch It (Stakeholders)

To executives: This is a small, permissively licensed Symfony bundle for talking to Salesforce's REST API. It is not a strategic dependency and I do not recommend adopting it as one — it has seen no releases since 2020 and has no downstream users, so there is no maintenance signal behind it. Its value to us is as a cheap reference for scoping our own integration, which materially de-risks the build estimate. Recommendation: fund a short discovery spike, not an adoption.

To engineering: Treat this as a pattern source, not a dependency. It's Symfony-DI-bound, so a Laravel adoption means a container/config bridge we'd own forever, on top of owning the code itself. If we fork it, we pin it, we own patching, and we accept that it stops at basic CRUD/SOQL — everything beyond that (Bulk, events, modern OAuth) is ours to build. The upside is that it confirms the core client is a small, bounded piece of work rather than an open-ended platform bet.