Choosing the flow per subject

Register a resolver once to map a subject to the flow key it should use, instead of branching by hand:

Onboarding::resolveUsing(fn ($subject) => $subject?->isAdmin() ? 'admin' : 'default');

Onboarding::for($user);                 // the resolved Flow, bound to $user
Onboarding::resolveFor($user);          // the same
Onboarding::resolveFor($user, 'team');  // the same, falling back to "team" instead of "default"
$user->resolvedOnboarding();            // the same as Onboarding::for($user), from the GetsOnboarded trait

• The resolver receives the subject — a Model, an Authenticatable or null — and returns a flow key or null.
• Onboarding::for($subject) without a key — and resolveFor() — return a copy of the resolver’s flow, bound to the subject, when that key is registered.
• When the resolver returns null or an unknown key, they fall back to the default flow — or to the key passed as resolveFor()’s second argument; they return null only when neither exists.
• flush() clears the resolver along with the registered flows.

Resolver versus default key

Every place that reads a subject’s flow without a key asks the resolver first: $user->onboarding(), the model readers (hasCompletedOnboarding(), isOnboarding(), onboardingProgress(), nextOnboardingStep(), dismissOnboardingStep()) and the onboarding middleware. On a model, a null or unknown answer falls back to its defaultOnboardingKey(). An explicit key — $user->onboarding('admin') or onboarding:admin — always wins:

class User extends Model
{
    use GetsOnboarded;

    // the fallback when the resolver answers null or an unknown key
    public function defaultOnboardingKey(): string
    {
        return $this->onboarding_flow ?? 'default';
    }
}