Most important business processes do not finish in one sitting. A new employee needs information from home. A customer leaves checkout to find a number. A vendor starts an application on a phone and wants to finish it later on a laptop.

Software often treats that pause as a failure. The person returns to the first screen, finds empty fields, and decides the work is not worth repeating.

Livewire Workflows 1.0 makes the pause part of the product. The first stable release adds signed resume links that can return someone to the current incomplete step of a workflow. It also changes the package's default state storage from a browser session to the database, which is the less visible decision that makes those links dependable.

I built Livewire Workflows for the part of business software that looks simple on a diagram and becomes difficult in code. Onboarding, checkout, applications, approvals, surveys, and setup wizards all share the same hidden machinery: routes, step order, completion rules, saved state, back navigation, progress, access control, and events.

Version 1.0 does not replace that foundation. It makes the foundation durable enough for a person to leave and return.

A workflow is more than a long form split across pages

A multi-step form is easy when every person follows the same path. Page one goes to page two. Page two goes to page three. Submit.

Real workflows branch.

An existing customer may skip identity details. A new account may need email verification. A large order may need approval. A completed training step should not appear again. A person who uses the Back button should return to the correct prior step, not simply the prior URL.

Livewire Workflows defines those rules in a route-like DSL:

Workflow::flow('onboarding')
    ->entersAt(name: 'onboarding.start', path: '/onboarding')
    ->finishesAt('dashboard')
    ->step('verify-email')
        ->goTo(VerifyEmail::class)
        ->unlessPasses(EmailVerifiedGuard::class)
        ->order(10)
    ->step('profile')
        ->goTo(EditProfile::class)
        ->unlessPasses(ProfileCompletedGuard::class)
        ->order(20);

The package registers the routes, evaluates guards in order, sends the person to the first incomplete step, tracks progress, supports workflow history, and fires lifecycle events. Step components use Livewire, while the workflow definition remains a readable map of the process.

The guard language is deliberate. A guard that passes means the requirement is already satisfied, so the related step can be skipped. unlessPasses() reads as the product rule: show this step unless the customer already completed it.

That base works with Laravel 11, 12, and 13, and with Livewire 3 or 4. Version 1.0 keeps those contracts and adds a way back into them.

The new resumeUrlFor() method creates a temporary signed Laravel URL for a user or an explicit workflow key:

$url = workflow('onboarding')->resumeUrlFor(user: $user);

$url = workflow('onboarding')->resumeUrlFor(
    userKey: 'guest-abc123',
    expiresInMinutes: 60,
);

The default expiry is 24 hours and can be changed in configuration. When the link opens, the package looks up the saved current step. It redirects to that step when it is valid, or to the workflow entry route when no step has been stored.

This also works for workflows whose routes contain parameters. A checkout path may include a user and a product. The package stores those route parameters with the workflow state and restores them during the resume redirect. Returning to "shipping" without the order, user, or product that gives the step meaning would not be a real resume feature.

For the business, this creates a simple recovery tool. An application reminder can return to the unfinished section. An onboarding email can continue after the customer verifies something outside the app. A staff member can send a valid link instead of explaining how to navigate back through a portal.

The link does not remove every source of abandonment. It removes the punishment for taking a break.

Why the database is now the default

Before version 1.0, the package defaulted to session-backed state. That was convenient for a quick setup because the browser session already existed. It was also tied to that browser session.

A cookie can expire or be cleared. A person can switch devices. An emailed link can open in a different browser. The application may know which workflow key the link refers to while the browser that opens it has none of the original session state.

Version 1.0 changes the default repository to Eloquent. Workflow progress lives in a database record keyed by workflow and user. The state can survive the browser that started it, which is a requirement for meaningful resume links.

New installations now publish the workflow-state migration as part of workflows:install. The old --with-db option is gone because database setup is no longer treated as an optional production extra. The session repository remains in the package for now, but it is deprecated and does not support resume links.

This is a strong default because it matches the promise the product makes. If an application tells a customer, "You can come back later," the saved progress should not depend on the continued life of one browser cookie.

The upgrade has a real break

Existing applications can run:

php artisan workflows:upgrade

The command checks the configured repository, explains the change, asks for confirmation, publishes the database migration when needed, runs the migration, and updates a published config file from the old session or null default to Eloquent.

It cannot move current session-backed progress into the database.

That is not a missing migration script. Session state is keyed by a session identifier that has no reliable relationship to a user record. Guessing that relationship would risk attaching one person's workflow state to another person. The upgrade refuses to invent an identity link that the old storage never had.

Any customer who is midway through a session-backed workflow will restart after the application changes repositories. A team should therefore plan the upgrade around the life of its workflows. If most flows finish within one day, it may wait for a quiet window and warn affected users. If a flow stays open for weeks, the application may need a separate transition plan before it changes the default.

That is the business meaning of a breaking change. The code update is short. The customer-state decision needs thought.

Laravel signs the resume URL with the application's key and an expiry. If someone changes the workflow name, user key, expiration, or another signed value, validation fails with a 403 response. An expired link also fails.

That proves the application created the URL and that the URL was not changed. It does not prove that the person opening it is the intended customer.

Anyone who receives a valid link may be able to open it. Email forwarding, shared inboxes, copied browser history, and support transcripts can all move links between people. A workflow that exposes private records, financial details, health information, or account controls still needs authentication and authorization that match the risk.

The package documentation states this boundary directly. Engineers should treat the signed URL as safe navigation, not as a replacement for login or a policy check.

The same rule applies to an explicit guest key. The key lets the package find durable state for a person who may not have an account. It is not proof of identity by itself. Use a short expiry, limit what the resumed screen can reveal, and add another verification step when the workflow carries sensitive data.

Try the package in the testbench

The fastest way to understand a workflow package is to use a complete workflow, not only read an isolated code sample. The Livewire Workflows testbench is a working Laravel application with four examples you can run locally.

The registration flow collects account, business, demographic, and subscription details. The login flow demonstrates optional MFA and conditional subscription and payment steps. The appointment flow moves through service, provider, time, and confirmation. The checkout flow covers cart review, shipping, billing, payment, and order confirmation.

Together, these examples show the package's route DSL, Livewire step components, guards, state, back navigation, and completion behavior in context. They also give engineers a safe place to change a guard, reorder a step, interrupt a flow, and inspect what happens before they introduce the package into an existing application.

The repository README includes the local setup commands and the URL for each example. Clone the testbench repository, run its migrations and seed data, and start with the registration or appointment flow. Then leave midway through a process and inspect the state that makes a later return possible.

Stable does not mean finished forever

The 1.0.0 label matters because it marks the package's first stable release. The route DSL, guards, Livewire integration, state repositories, progress tracking, events, dynamic parameters, controller steps, workflow middleware, audit command, and Livewire 4 support had already developed across the 0.x releases. Version 1.0 puts a stable version number on that system and makes durable progress the normal setup.

It does not mean every business process now fits one package. A workflow may still need domain-specific approvals, audit history, document rules, payment controls, or coordination with outside systems. Those belong in the application. The package handles the repeated navigation and state machinery so the custom work can focus on what makes the process different.

That distinction is why I built it. The valuable part of an onboarding system is not the code that calculates 50 percent progress. It is the decision about what someone must complete, what they can skip, what can expire, who may approve it, and how the business responds when they stop halfway through.

Version 1.0 gives that process a durable spine. A customer can leave. Their progress can remain. The application can bring them back to the right place without pretending a signed link solves identity.

If a checkout, onboarding process, or internal approval has grown past a chain of conditionals, our TALL stack development work and custom software work are built for that kind of problem. Tell Pixelworx where the process breaks.