Salesforce Bridge Bundle Laravel Package

Technical Evaluation

Architecture fit — primary finding: this is not a Laravel package. Release 1.0 of maillotf/salesforce-bridge-bundle is a Symfony bundle. It ships a Symfony DI extension, YAML configuration under a salesforce: root key in framework.yaml, and service wiring in services.yaml. A Laravel application has no mechanism to load a Symfony bundle: there is no service provider, no config/salesforce.php publishable config, no facade, no env-var mapping, and no auto-discovery. The headline for any TPM evaluating this against a Laravel codebase is that installation is not the integration — a port is.

What is reusable. The underlying SalesforceService (e.g. getBySobjectId()) appears to be a plain PHP service with a response object exposing isSuccess(). If it does not depend on Symfony-specific container or HTTP abstractions, the class is extractable and bindable in Laravel's container in a few hours. Everything around it — config loading, credential wiring, service aliasing — must be rebuilt.

Integration feasibility.

• Framework constraints are Symfony 4 / PHP 7. Symfony 4 reached end of life in November 2023; PHP 7.4 reached end of life in November 2022. Neither is a defensible target for new work.
• Composer resolution will likely fail outright in a modern Laravel application (Laravel 10/11 require PHP 8.1+ and Symfony 6/7 components). Forcing it with --ignore-platform-reqs trades a clean failure for a runtime failure.
• The documented services.yaml alias (SalesforceService: '@salesforce.service') is illustrative rather than a complete wiring example, and the controller sample mixes a capitalised variable with PSR-12 style — a signal that the docs were not exercised against a fresh skeleton.

Authentication — the material risk. The package uses the Salesforce username–password + security token OAuth flow. Salesforce has been actively restricting this flow: it is disabled by default for newly created connected apps and is not an approved pattern for new integrations. It also ties the integration to a human user account, so a password change, a security token reset, MFA enforcement, or a login IP range change breaks production silently. The supported alternatives (JWT bearer flow with a certificate, or client credentials for server-to-server) are not offered.

API version. The sample configuration pins rest.version: "v35.0", a Salesforce API version from roughly 2016. Salesforce retires API versions on a rolling basis; anything near v35 is past or approaching end of support. It is configurable, but the documented default is a strong signal the package has not tracked the platform in years.

Credential handling. Client secret, user password, and security token are all expected in plaintext YAML committed to the repository. There is no secret-manager integration, no key-rotation path, and no indication of redaction in logs. This is likely to fail a security review and can block procurement in regulated environments.

General maturity signals. Version 1.0 with a single maintainer, no changelog, no stated semantic-versioning policy, no visible test suite or CI configuration, no security disclosure contact, and no license information in the notes. There is no evidence of a bulk API, SOQL pagination, retry/backoff, or rate-limit handling.

Key questions to resolve before any commitment.

1. Who maintains this, what is the release cadence, and is there a bus factor above one?
2. What is the license, and does it permit a fork?
3. Does SalesforceService depend on Symfony's HttpClient or on Guzzle/PHP streams — i.e. is it extractable at all?
4. Is the username–password flow still enabled on our target Salesforce org, and does our security policy allow a human-credentialed integration?
5. What happens on a 401, a REQUEST_LIMIT_EXCEEDED, or a session-limit error — is there typed error handling or does it throw raw exceptions?
6. Is there any test coverage we could inherit, or would a fork start from zero?

Integration Approach

Stack fit verdict. Poor, as-is. Symfony 4 + PHP 7 is two major framework generations and two language minor versions behind a current Laravel stack. Treat this as a reference implementation, not a dependency.

Options, in order of preference.

1. Do not adopt; use a maintained alternative. For a Laravel codebase, a first-party-style integration (Laravel HTTP client or a maintained Salesforce REST SDK) with JWT bearer or client-credentials auth gives current API version, retry semantics, testability via Http::fake(), and a supportable upgrade path. This is the default recommendation.
2. Fork and re-platform as a Laravel package. Viable if, and only if, the underlying service class is worth salvaging. Scope: service provider with deferred binding, publishable config/salesforce.php driven by env vars, facade for convenience, replacement of the auth layer with JWT bearer, API version bumped to a currently supported release, retry/backoff and structured logging (credential redaction mandatory), and a test suite against a mocked HTTP layer. Estimate two to four engineer-weeks including tests, plus an ongoing maintenance owner.
3. Timeboxed spike only. Wrap getBySobjectId in a throwaway project, confirm the auth flow works against a sandbox org, and record the result. Do not deploy.

Migration path (if option 2). Extract the service class and its response object → replace Symfony DI with a Laravel container binding → move YAML keys to config + env → swap auth to JWT bearer with a certificate in the secret manager → bump API version → add retry/backoff and logging → publish behind our own SalesforceClient interface so the vendor can be swapped later without touching call sites.

Compatibility matrix to pin explicitly. PHP version, Laravel major, Symfony components we transitively rely on, and Salesforce API version. Salesforce API versions are the sneaky one — a version bump on their side can break us with no change on ours.

Sequencing.

1. Confirm with the Salesforce admin whether username–password flow is enabled for our org and permitted by policy. If no, half this package is unusable and the decision is made.
2. Run the timeboxed spike against a sandbox, reading only.
3. Decide build vs. buy with the spike result in hand.
4. If building, place the Salesforce client behind an internal interface before the first production call site exists.
5. Pilot read paths (getBySobjectId) in one low-risk feature, then expand to writes only after error handling and rate-limit behaviour are understood.

Operational Impact

Maintenance. If we fork, we own it permanently — upstream will not track Laravel releases, PHP releases, or Salesforce API retirements. Even without a fork, adopting this means owning a dependency with no observable maintenance signal. Budget an explicit ongoing allocation rather than assuming the community absorbs it.

Support. Single maintainer, no SLA, no stated security contact, no changelog. Assume issues go unanswered and plan for internal ownership of every defect. There is no vendor to escalate to, which makes this a materially different risk profile from a commercial SDK.

Scaling. Three constraints bite as volume grows:

• Credential/session model. The username–password flow authenticates as a specific user; concurrent API sessions are capped per org, and a shared integration user compounds that with every other tool using the same account.
• Synchronous calls in the request cycle. The documented usage calls Salesforce inline from a controller. Every page request inherits Salesforce latency plus network variance. No batching, no bulk API, no queueing is offered, so the integration must be moved behind jobs for anything beyond trivial volume — which is work the package does not do for us.
• API request allocation. Salesforce enforces daily API request limits per org. Without caching or batching, a moderately trafficked endpoint can exhaust the org's allocation and take down unrelated integrations.

Failure modes to instrument for.

• Password change, security token reset, or MFA enforcement on the integration user → hard 401 across all features.
• Login IP range or connected-app policy change → same.
• Salesforce API version retirement → 400/410 on endpoints that worked yesterday, with no code change on our side.
• REQUEST_LIMIT_EXCEEDED under load.
• Credential leakage: plaintext password and token in YAML, committed to version control, potentially echoed in exception traces.
• Composer resolution failure at deploy time when PHP or Laravel is upgraded — a build-time failure that looks like an outage if it lands mid-release.

Ramp-up. For a Symfony developer, low: two YAML blocks and one injected service. For a Laravel team, high. There is no Laravel documentation, no service provider to register, no config to publish, and no example of SOQL, pagination, or error handling. Onboarding means reading the bundle source to determine what is actually safe to call. Assume one to two days of source reading before the first confident integration, and note that the team will be reverse-engineering behaviour the README does not describe.

Governance. Plaintext user credentials in configuration is very likely to fail a security review outright, independent of the technical merits. Route this past security and compliance before any engineering time is spent, because a rejection there invalidates the build-vs-buy analysis entirely.