Salesforce Bridge Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for Salesforce integration. This is a thin, single-maintainer Symfony bundle that wraps a username/password Salesforce REST client. The build-vs-buy question is really "adopt vs. spike": the package saves days of REST boilerplate, but the boilerplate it saves is the part any competent engineer writes once and controls.
• Framework-fit decision (the deciding one). The package is a Symfony 4 bundle, not a Laravel package. For a Laravel roadmap it is not directly consumable without an adapter/service-provider shim, and it would drag Symfony 4 conventions into a Laravel codebase. This is a "note the mismatch and move on" item unless the team has a legacy Symfony 4 service.
• Legacy-modernization sequencing. The bundle pins API version v35.0 (circa 2016) and username + password + security token authentication. That makes it useful mainly as evidence of what a legacy integration looks like, and as a scoping input for a migration plan to OAuth 2.0 (JWT bearer / connected app) and a current API version.
• Use cases it can credibly support today: internal back-office read/update of SObjects in an already-existing Symfony 4 / PHP 7 app; a time-boxed proof of concept to validate a Salesforce data flow before committing to a real integration; a throwaway admin utility.
• Use cases it should not be attached to: customer-facing features, anything on the critical path, multi-tenant credential handling, high-volume or bulk data movement, or any org where security review has veto power.
• Roadmap signal: the 1.0 label is a version number, not a maturity claim. The release notes contain typos ("symphony", "instalation"), no license statement, no test or CI evidence, and no changelog. Plan for the maintenance burden to land on your team.

When to Consider This Package

Consider it only when all of the following hold:

• The application is Symfony 4.x on PHP 7.x and is not being upgraded in the planning horizon.
• The integration is internal, low-risk, and low-volume — a handful of record reads or updates per user action.
• The Salesforce org still permits username/password/security-token authentication for this integration, and that has been confirmed with the Salesforce admin rather than assumed.
• A security review has explicitly accepted long-lived credentials in framework.yaml, or secrets are externalized.
• You need something working this sprint and are willing to own the code as if you had written it — because you will be.

Look elsewhere when any of these apply:

• You are on Laravel. There is no service provider, no config publishing, no Laravel-native HTTP client usage, no queue/retry integration. Adapting it costs more than writing a small Laravel-side client against Salesforce's REST API.
• You are on PHP 8 / Symfony 5+. PHP 7 and Symfony 4 are both end-of-life; adopting this pins you to unsupported runtimes.
• You need modern Salesforce auth. New connected apps are increasingly steered away from the password flow; OAuth 2.0 JWT bearer or the official Salesforce PHP SDK is the durable choice.
• You need Bulk API, Streaming/Pub-Sub, Composite API, webhooks, or platform events. The release notes show a single getBySobjectId-style surface; assume those are absent.
• You need a maintained dependency. One author, version 1.0, no stated support policy, no license file, no tests, no CI — this fails most dependency intake checklists. A procurement or supply-chain review will likely stop it.
• You need framework-agnostic code. A Symfony bundle is heavier to unwind than a plain client library.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, single-author Symfony bundle that lets a PHP application read and update Salesforce records with about ten lines of configuration. It costs nothing to try and could save a few days on an internal tool. But it is built for Symfony 4 and PHP 7 — both end-of-life — and it authenticates with a Salesforce username and password, an approach Salesforce is actively steering customers away from. My recommendation is to treat it as a prototype accelerator, not a platform commitment: use it to prove a data flow in a spike, then fund a small, properly authenticated client before anything reaches production. It is not a Laravel package and should not be adopted into a Laravel codebase as-is.

For engineering: The package is a thin wrapper over the Salesforce REST API, configured via framework.yaml with client ID/secret, username, password, and security token, and exposed as a single injected SalesforceService. The public surface demonstrated is narrow — fetch-by-SObject-ID with a success check. Expect to own it: no tests, no CI, no license, no changelog, and a pinned API version (v35.0). Budget for (a) a Laravel service-provider or Symfony-container adapter if the framework differs, (b) replacing the auth layer with OAuth 2.0 JWT bearer, and (c) raising the API version. If the total of those three exceeds roughly a sprint, write the client directly against Salesforce's REST API — the wrapper is not doing enough to justify the coupling.

For security and platform review: Flag two items explicitly before any pilot. First, the authentication model embeds reusable user credentials and a security token in application configuration — this needs a secrets-management answer and an exception sign-off, not a default. Second, the runtime stack (PHP 7, Symfony 4) receives no upstream security patches, so any production use inherits known-unpatched exposure. Both are blockers for customer-facing scope and usually acceptable only inside a time-boxed internal pilot.