Laravel Temporal Laravel Package

Product Decisions This Supports

• Workflow orchestration vs. queue chaining: Informs whether multi-step business processes (order fulfillment, payment capture + reconciliation, KYC/onboarding, subscription lifecycle, vendor sync, ETL handoffs) should be modeled as Temporal workflows instead of nested Laravel jobs, Bus::chain, cron stitching, or custom state tables.
• Build vs. buy for reliability plumbing: Weighs adopting Temporal (self-hosted or Temporal Cloud) with this package as the Laravel adapter against hand-rolling retries, idempotency keys, timeouts, compensation/saga logic, and "stuck job" dashboards. The package's value is largely in eliminating bespoke orchestration code, not new end-user features.
• Roadmap sequencing: A credible enabler for roadmap items that are currently blocked on reliability concerns — anything requiring durable timers (e.g., "remind in 14 days"), long-running human-in-the-loop approvals, or cross-service consistency.
• Dependency and platform surface area: The 2.3.2 fix (spatie/laravel-data no longer required for workflows to run) confirms optional integrations are isolated, so adoption does not force an unrelated serialization standard onto teams. Relevant to architecture standards and package-approval decisions.
• Not a decision driver for: short-lived single-step jobs, UI work, or features that don't cross process boundaries. Keep those in the existing queue.

When to Consider This Package

Consider it when:

• A process spans multiple steps, services, or human approvals and must survive deploys, restarts, and partial failures.
• You need durable timers and long delays (days/weeks) with reliable execution, not cron approximations.
• Failure handling is business-critical: retries with backoff, compensation/rollback, and "where exactly did this order get stuck?" visibility matter to support and finance.
• You are already on Laravel and want Temporal without abandoning Laravel idioms (queues, container, facades, config).
• You need auditability/traceability of each step for compliance or customer support.
• You want the option of Spatie Laravel Data serialization without a hard dependency — 2.3.2 makes that explicit.

Look elsewhere when:

• The workload is simple, single-step, or low-volume — native queues and retryUntil are cheaper.
• Sub-100ms latency is the requirement; workflow orchestration adds round-trips and a cluster dependency.
• The team has no appetite to operate (or pay for) a Temporal cluster/namespace, or lacks on-call capacity for a new stateful system.
• You need a purely serverless or vendor-managed-only footprint with no external orchestration service.
• The process is inherently a single transaction and a database transaction already suffices.

How to Pitch It (Stakeholders)

To executives: This is infrastructure that makes long-running business processes — orders, payments, onboarding, partner syncs — complete reliably instead of silently dying halfway. The payoff is fewer stuck records, less manual cleanup by support/ops, and faster delivery of roadmap features that depend on multi-step reliability. It is an adapter, not a new platform bet: it sits on Temporal, which can be self-hosted or consumed as a managed service, so cost and lock-in are controllable.

To engineering: Laravel-native Temporal integration — workflows and activities as first-class citizens with queue and container integration, so we stop reimplementing retries, timeouts, and saga/compensation logic per feature. Workflow state is durable and inspectable, which shortens incident triage. The 2.3.2 patch is a low-risk maintenance fix: it resolves a crash in workflow execution when spatie/laravel-data is absent, meaning we can adopt without standardizing on that package. No breaking changes, no migration work, drop-in upgrade from 2.3.1.

Recommendation: Approve a time-boxed spike on one real multi-step flow to validate operational overhead before committing broadly. Track cluster ownership, observability, and serialization conventions as the gating criteria.