Binding the subject

A flow evaluates its steps against a subject — an Eloquent Model or any Illuminate\Contracts\Auth\Authenticatable. Get a subject’s flow with Onboarding::for():

Onboarding::for($user)?->percentageCompleted();            // the resolver's flow, else "default"
Onboarding::for($user, 'admin')?->percentageCompleted();   // a specific flow by key

Onboarding::find() returns the registered definition itself. Read from it without binding and it uses the authenticated user — auth()->user() — at read time. An explicit subject always wins:

// binds auth()->user() implicitly
Onboarding::find('default')?->percentageCompleted();

// an explicit subject always wins
Onboarding::for($otherUser)?->percentageCompleted();

In a context with no auth — a plain unit test, a queue job with no user — the subject stays null. Rules and declarative helpers all tolerate a null subject.

Each subject gets its own copy

Onboarding::for(), resolveFor() and the model trait return a copy of the registered flow — its steps cloned too — bound to the subject. Two subjects’ flows never share state, even in one request, job or long-running Octane worker, and the registered definition stays unbound:

$mine = Onboarding::for($user);     // a copy bound to $user
$theirs = Onboarding::for($admin);  // another copy, bound to $admin

$mine?->percentageCompleted();      // still evaluates $user
$user->onboarding();                // the trait returns a copy too

// find() hands back the registered definition itself — add steps to it at boot,
// but read through for() so no subject is ever bound to the shared instance
Onboarding::find('default')?->add('Invite your team');

Subjects in events

The subject travels on StepCompleted and FlowCompleted as $for. Because a subject can be any Authenticatable, listeners hinting ?Model $for should be ready for a non-Model subject too.