Salesforce Bundle Laravel Package

Product Decisions This Supports

• CRM data exchange in a Symfony 2–era application: pushing/pulling Leads, Contacts, Accounts, Opportunities, Cases, and custom objects against the Salesforce API.
• Lead capture and routing: ingesting form/web leads into Salesforce and letting assignment rules run.
• Support workflows: creating Cases from in-app actions and surfacing case status back to users.
• Sales-ops reporting: pulling pipeline and opportunity data into internal dashboards.
• Build vs. buy scoping: use it as a "buy" candidate (off-the-shelf bridge) versus writing a thin in-house client against the Salesforce REST API — the source is a useful effort-estimation reference even if you never ship it.
• Legacy modernization decisions: evidence of how Salesforce connectivity was historically handled in Symfony apps, feeding the "keep vs. replace" call during a framework migration.
• Architectural caveat for the roadmap: this is a Symfony2 bundle, not a Laravel package. Symfony bundles depend on the Symfony kernel/DI container, so it does not drop into a Laravel app; adopting it in a Laravel product effectively means a port, not an install. Factor that into any timeline.

When to Consider This Package

Consider it only when:

• The host application is a Symfony 2.x/3.x app already using bundles and the Symfony DI container.
• You are maintaining a legacy integration and need a like-for-like escape hatch to avoid a larger rewrite.
• You want to read the source as a reference for how a thin Salesforce wrapper was modeled (auth flow, object mapping, service registration).
• The integration is low-volume and non-critical, and you are prepared to vendor/pin the code and own it entirely.

Look elsewhere when:

• You are on Laravel or any non-Symfony framework — bundles are not portable; you would be rewriting the wiring regardless.
• You need PHP 8+, current Salesforce API versions (Salesforce retires API versions roughly three years after release), OAuth 2.0 JWT bearer flows, or modern TLS/crypto.
• You need maintenance, security patching, or a vendor SLA — last release 2015-05-06, 0 stars, 0 dependents means no community validation and no upgrade path.
• You need Bulk API, Pub/Sub, or platform events — a 2015-era wrapper will not cover modern Salesforce surfaces.
• Compliance or auditability matters (SOC 2, data residency, secret management) — an abandoned dependency is a finding waiting to happen.

Reasonable alternatives: a maintained Laravel Salesforce client (e.g., omniphx/forcedotcom), Salesforce's REST API called directly over Guzzle/HTTP, or a small owned client — all give you current API versions and a support path.

How to Pitch It (Stakeholders)

Executives: "There's a 2015 Symfony bundle for Salesforce integration. It is effectively unmaintained — zero stars, zero dependents, no release in a decade — and it targets Symfony 2, not our Laravel stack. I don't recommend adopting it for new work: the risk of building on an abandoned dependency outweighs any short-term savings. For our roadmap, a thin owned integration against the Salesforce REST API (or a maintained Laravel client) costs roughly the same to build and gives us support, security updates, and control."

Engineering: "It's a small Symfony bundle wrapping Salesforce's APIs — useful as a design reference for auth flow, object mapping, and service registration, not as a dependency. Porting it to Laravel means replacing the bundle/DI wiring with a service provider and re-testing every call against a current Salesforce API version, at which point you've written the integration anyway. Recommendation: treat it as a pattern source and build or vendor a thin client instead."