Laravel5 Salesforce Laravel Package

Technical Evaluation

Architecture fit

The package is a thin Laravel service-provider wrapper around the legacy Force.com PHP Toolkit (SOAP Partner/Enterprise client). Its shape is conventional for Laravel 5.x: a ServiceProvider, a Facade, a published config/salesforce.php (username, password, security token, WSDL path, SOAP options), and a Salesforce class that extends the toolkit's SforcePartnerClient/SforceEnterpriseClient so that login(), query(), create(), update(), describeSObjects() etc. are called through the container. That is a convenience wrappers, not an abstraction: SDK types (SObject, SforcePartnerClient, raw stdClass rows) leak directly into application code, and there is no repository/DTO boundary, no retry policy, no queue integration, and no test seam.

For a TPM this matters: the package accelerates a demo and impedes a production integration. Anything beyond a read-only SOQL query will require an anti-corruption layer we own.

Integration feasibility

Low cost to prove, high cost to productionize. Standing up a sandbox connection is roughly an afternoon (require, register provider/facade, publish config, drop in a WSDL, login() + query()). Making it production-grade requires: an adapter interface around the client, DTO mapping for each object, idempotency via external IDs, retry/backoff, error taxonomy, and tests against a fake — none of which ship with the package.

Hard prerequisites we must confirm before committing:

• ext-soap enabled on all app/worker hosts, and outbound HTTPS to login.salesforce.com / *.my.salesforce.com.
• PHP and Laravel version compatibility. This is a Laravel 5-era package; the underlying toolkit predates PHP 8 (each(), create_function, dynamic-property deprecations). Verify on our actual runtime rather than trusting composer.json.
• Package auto-discovery (extra.laravel) is likely absent — expect manual providers/aliases registration, which breaks on Laravel 11's slim skeleton.
• A current WSDL. Salesforce retires API versions on a rolling ~3-year window; a stale bundled WSDL is the single most common breakage.

Technical risk

• Maintenance risk: high. 47 stars, 0 dependents, effectively single-maintainer and dormant. Treat it as an unmaintained fork we inherit on day one.
• Auth risk: high. Username + password + security token is a legacy flow. Enterprise security review will likely push for OAuth 2.0 JWT bearer or Connected App client-credentials, which this package does not model.
• Protocol risk: medium. SOAP Partner/Enterprise is still supported, but it is the least strategic surface Salesforce maintains; every new capability (Bulk API 2.0, Composite, Platform Events, CDC) is REST-first.
• Vendor lock-in risk: low-medium. MIT license means we can fork; the practical lock-in is the toolchain knowledge, not the license.
• Score context: 1.315 overall against an opportunity score of 7.11. Read that as real, unmet demand for Salesforce integration paired with a package that does not meet it. The opportunity is the integration; this artifact is not the vehicle.

Key questions

1. Target Laravel and PHP versions, and which runtime image ships ext-soap?
2. Read-only sync, one-way writes, or bidirectional? Which objects, and what daily record volume / peak burst?
3. Does volume exceed the ~2,000-records-per-call practical SOAP ceiling, forcing Bulk API 2.0?
4. Will Security accept username/password/security-token, or mandate OAuth 2.0 + Connected App?
5. Is there an existing iPaaS (MuleSoft/Workato/Segment) that should own this instead of the app?
6. Who owns the fork, and is there budget for that ownership?
7. Does the Salesforce edition's 24-hour API request allocation cover our design (session reuse, polling frequency)?

Integration Approach

Stack fit

Fits only on Laravel 5.5–6.x with PHP 7.x and SOAP permitted. On Laravel 9+ or PHP 8.2+, do not adopt the package. The pragmatic alternatives, in order of preference:

1. Greenfield / REST-first: omniphx/forrest (REST + OAuth) or a hand-rolled Laravel HTTP-client integration against the REST/Composite/Bulk 2.0 APIs. Best long-term fit; idiomatic Laravel Http facade gives us retries, timeouts, and Http::fake() tests for free.
2. SOAP required (WSDL-defined custom objects, Partner WSDL workflows): depend on the maintained phpforce/soap-client fork directly and write our own ~80-line service provider. This keeps the useful part and drops the unmaintained Laravel glue.
3. Adopt this package only for a time-boxed spike, with a hard commitment to replace before GA.

Migration path

If we start on the package for velocity, isolate it immediately: define SalesforceClient (our interface) with query, upsert, delete; implement LegacyToolkitAdapter wrapping the package; bind in a service provider. Every caller depends on the interface. Swapping to REST later becomes one class plus a config flag — not a refactor. This is the single highest-leverage decision in the whole evaluation.

Compatibility

Verify by executing, not reading: composer why-not php ^8.2, a sandbox login, a SELECT Id FROM Account LIMIT 1, and a create/update round-trip. Check WSDL API version against Salesforce's supported-version matrix and pin it explicitly in config so upgrades are deliberate.

Sequencing

1. Week 1 — spike. Sandbox org, Connected App, WSDL, verify auth and a query. Decide SOAP vs REST on evidence.
2. Week 1 — risk gate. Security review of credential flow; confirm API allocation math against projected volume.
3. Week 2–3 — adapter + contract tests. Interface, DTOs, mapping tables (Salesforce field ↔ domain field), fake client for CI.
4. Week 3–4 — write path hardening. Move all writes to queued jobs, idempotent via External_Id__c upserts, bounded retries with exponential backoff, dead-letter table.
5. Week 4 — observability. Structured logs per API call (operation, object, row count, latency, fault code), metrics, alert on fault-rate and session-expiry spikes.
6. Week 5 — load test and cutover against a full-volume sandbox refresh.

Operational Impact

Maintenance

Assume we own it. The package is dormant; there is no upstream to wait for. Budget ongoing ownership: WSDL/API-version currency (annual, minimum), PHP/Laravel upgrade compatibility, and ext-soap presence in every new container image. Call it 10–20% of one engineer ongoing if forked and lightly customized; closer to 5% if we keep it strictly read-only and behind an adapter.

Support

No vendor, no SLA, minimal community. Salesforce Support will not troubleshoot toolkit behaviour — they will point at the API and close the case. Internal runbooks must therefore encode the diagnosis path: is it auth, WSDL, SOQL, or Salesforce-side governor limits?

Scaling

The scaling ceiling is Salesforce's, not ours:

• API request allocation (per 24h, edition- and license-dependent, roughly 15k to 5M+). Session handling is the biggest lever — a login() per web request silently burns allocation and will exhaust it under normal traffic. Login once, cache the session ID, handle INVALID_SESSION_ID by re-authenticating once.
• SOAP call size. Batch writes (~200 records per call is a safe operating point, 2,000 is the hard ceiling but fragile). Above a few thousand records/day or any backfill, switch to Bulk API 2.0 — this package cannot do it.
• SOQL query locators. Large result sets must page via queryMore; timeouts on wide queries are common and need explicit handling.
• Concurrency. Salesforce enforces concurrent long-running request limits; queue workers must be capped, not scaled naively with the rest of the fleet.

Failure modes to instrument explicitly

• INVALID_SESSION_ID — session expiry / org restart.
• INVALID_LOGIN — security token rotation, password change, or IP not in the org's trusted ranges (very common after a network change).
• REQUEST_LIMIT_EXCEEDED — allocation exhaustion; needs a circuit breaker, not retries.
• SOAP fault on partial batch success — toolkit surfaces per-record errors inside a success envelope; naive try/catch will report success while records silently failed. This is the most dangerous failure mode and must be handled field-by-field.
• WSDL cache staleness after a Salesforce release — clear and regenerate on a schedule.
• Silent duplicates from non-idempotent create() calls on retry.
• Timeout mid-write with unknown commit state — requires a reconciliation job, not a blind retry.

Ramp-up

One backend engineer, roughly 1–2 weeks to production-ready including adapter, mapping, queueing, and tests — provided the SOAP path is validated in week 1. If Security mandates OAuth 2.0 or volume forces Bulk API, the package is out of scope entirely and the estimate becomes 3–4 weeks on a REST-based build. Recommend a one-week timeboxed spike with an explicit kill criterion, and pre-commit to the adapter boundary so the decision stays reversible.