Filament Onboarding Laravel Package

Product Decisions This Supports

• Whether onboarding becomes a roadmap item or a config change. The package moves journey definition into the panel, so "improve activation" stops competing with engineering sprints for capacity. That changes the cost side of the build-vs-buy equation decisively in favor of buy (MIT, free) for any Filament-based product.
• Build vs. buy for the onboarding surface. The alternative is a bespoke user_progress table, custom tour JavaScript, and hardcoded step copy — typically 2–4 weeks of eng plus permanent maintenance. This replaces that with a composer dependency, which is a straightforward "buy" unless the journeys are genuinely unique.
• Retroactive enrollment strategy for legacy cohorts. Condition-bound steps that self-complete mean users who predate the journey enter it already part-done. This directly supports a decision product teams usually punt on: whether to backfill onboarding for existing users or segment them out. Here you can backfill cheaply without telling a two-year veteran to "create your first project."
• Persona, plan, and — as of v1.2.0 — tenant segmentation. Journeys can be scoped per role, plan, or locale, and a step can now route a multi-tenant user to the panel's tenant profile, a destination the authoring picker previously couldn't see. "Finish setting up your team" becomes a first-class onboarding step rather than a support article, which makes a per-tenant onboarding journey a realistic product decision instead of a blocked one.
• Localization sequencing. Translatable to any locale means market expansion decisions (which locales to launch, in what order) don't have to wait on an engineering localization pass for onboarding copy.
• Iteration velocity as a tracked metric. Since PM/marketing can rewrite copy and reorder steps without a deploy, you can hold yourself to a real number — e.g., "onboarding copy change ships in <1 hour, not <1 sprint" — and use it to justify continued ownership by product rather than engineering.
• Reliability on complex admin forms as a buy-vs-build input. Until this release, a field nested under a Group, Section, Tab, or wizard step could not be targeted at all — the tour parked, Next stayed disabled, and the stall was written to localStorage so it returned on every reload. That is the worst possible onboarding failure mode, and it landed hardest on exactly the form-heavy panels worth touring. The fix (name matched at the end of the state path, not just as the whole of it) is what makes the "buy" case hold for a mature panel rather than a demo one.
• Support-cost reduction as a leading indicator. Guided tours plus a persistent checklist are a plausible deflection against CS ticket volume; worth instrumenting before/after rather than assuming.

When to Consider This Package

Adopt when most of these hold:

• The product surface is a Filament panel, on a version-matched line: v5 → the 2.x line; v4 → the 1.x line, which v1.2.0 proves is actively maintained and backported to (the two lines share source and differ only in Composer constraints and Livewire internals). This corrects the earlier position that v4 was a disqualifier — it no longer is, but confirm you're on the maintained line for your version before anything else.
• You pin a floor of 1.2.0 / 2.6.0. That release carries the fixes that matter operationally: nested-field targeting, hidden and horizontally offscreen targets, advance controls actually being pressed on resumed or cross-page tours, and worker-scoped definition caching. The last one is a correctness issue, not a polish item: if you run Octane or queue:work, a disabled journey could keep serving on every worker except the one that changed it. Below that floor, don't adopt.
• You have enough panel users that onboarding is a measurable funnel, not a courtesy (roughly: you can name an activation metric and its current value).
• Two or more cohorts (role, plan, tenant type) or multi-locale requirements exist — the segmentation, tenant-profile destination, and translation features are the real payoff.
• Your app already exposes the state conditions would bind to (has the user created a project? invited a teammate? completed a record?) — without those signals, condition-bound steps degrade into manual checkboxes.
• Your resources are not pathologically nested, or you're willing to verify targeting resource-by-resource in a pilot. The nested-field bug is fixed, but it was only found because a team measured the package against a real CMS panel.
• You want non-engineers authoring journeys and are willing to give up a deploy gate to get it.

Look elsewhere when:

• The onboarding in question is on a public marketing site or a non-Filament frontend — this is panel-scoped.
• You need rigorous experimentation (assignment, guardrails, statistical analysis). Authoring journeys in a panel is not an experiment platform; plan to pair it with your flag/analytics stack.
• You require vendor SLA, security review, or contractual continuity. Still an early-adopter dependency — but the picture has improved: v1.2.0 was substantially contributed by four outside developers who found and fixed real defects in production-shaped panels. Treat the bus factor as reduced, not resolved; keep the fork budget.
• The panel has tens of users, not thousands — a static help doc is cheaper to own than any onboarding system.
• Filament v3 or earlier.

How to Pitch It (Stakeholders)

To executives: Onboarding is one of the few activation levers we can pull without taking engineering capacity away from the roadmap. This is a free, MIT-licensed package that lets product own the onboarding experience end to end — we can rewrite, reorder, and localize journeys the same day instead of waiting for a release. It also solves the awkward case of existing customers: steps tied to real conditions complete themselves, so long-tenured users aren't asked to do things they did years ago. The latest release adds the multi-tenant case — sending a new customer to finish setting up their team is now a step we can author, not a support article we link — and it lands as a no-migration upgrade on the version line we'd be on. Expected effect: faster time-to-first-value, fewer "how do I…" tickets, and a segmentation story for new plans, tenants, and locales.

To engineering: Small, self-contained composer dependency. Journeys and steps live in the database, not in code — no new deploy surface for copy changes, no bespoke tour JavaScript to maintain. It ships with tests, a changelog, tagged releases, and docs. Costs you an install, a migration, and a place to register the condition callbacks we already have the state for. Two things to note from this release: pick the line that matches our Filament version (1.x for v4, 2.x for v5 — same source, different constraints), and budget a php artisan filament:assets in the deploy because the tour runner changed. The release also fixes a definitions cache that outlived the request under Octane and queue:work, so if we run long-lived workers this is the version that stops one process serving a journey another process already switched off.

The honest caveat, stated up front: this is still a young package — modest star count, few dependents, effectively a single maintainer. The mitigation is that it's MIT, the integration surface is narrow, and the 1.x line is being kept in lockstep with the 2.x line rather than abandoned, so worst case we vendor it and patch it ourselves; the migration path is our own database tables, which we keep. Recommend a time-boxed pilot on one panel and one cohort — including at least one deeply nested form resource, since that is where this class of tool historically breaks — with a defined activation metric, before we make it the standard for every journey.