Filament Invite Laravel Package

Product Decisions This Supports

• Invite-based user onboarding in admin/back-office apps: If the product is a Filament-powered internal tool, portal, or SaaS admin panel, this package covers a recurring "invite a teammate/customer" workflow that would otherwise be custom-built (token generation, signed URLs, expiry, email dispatch, acceptance flow, role assignment on accept).
• Build vs. buy on onboarding: Shifts the decision from "do we build an invitation subsystem?" to "do we accept the package's conventions?" Typically a multi-day build collapses into configuration, which is attractive for MVPs and internal tools where invitations are table stakes, not differentiation.
• Roadmap and upgrade planning: v2.0.2 adds Laravel 13 support. That signals the maintainer is tracking upstream framework releases, which matters if the product roadmap includes a Laravel major-version upgrade in the next 6–12 months. A dependency that lags Laravel majors becomes a blocker on upgrade timelines.
• Scope decisions for team/account features: Helps decide whether invitations belong in v1 or can be deferred. If the package covers the flow, invitations become cheap enough to include early; if it doesn't fit (SSO, SCIM, domain capture), that work stays on the roadmap as an explicit item.
• Platform standardization: For teams running multiple Filament panels, adopting one invitation mechanism reduces per-project reinvention and keeps the acceptance UX consistent across products.

When to Consider This Package

Adopt when:

• The application uses Filament and the invitation UI belongs in the admin panel — the value is highest when the panel is the product surface.
• Invitations are a supporting capability, not the differentiator: standard email invite → accept → account/team membership.
• The team wants the Filament-native path rather than wiring a general-purpose invitation package (e.g., spatie/laravel-invite or a bespoke implementation) into Filament resources.
• Laravel 13 is on the horizon or in use. v2.0.2 explicitly adds Laravel 13 compatibility, so this release is the one to pin if the framework upgrade is planned.
• The team accepts a small, single-maintainer package with a narrow surface area and is comfortable reading the source if edge cases appear.

Look elsewhere when:

• The onboarding requirements go beyond simple invites: SSO/SAML, SCIM provisioning, domain verification/capture, just-in-time provisioning, or complex multi-tenant role matrices. These need an identity provider or a dedicated auth platform, not a Filament plugin.
• The product is not on Filament — the package's value is largely its Filament integration, so a framework-agnostic invitation library is a better fit.
• Compliance or audit requirements demand vendor due diligence (SOC 2, support SLAs, security disclosure process) that a small community package cannot supply.
• You need guaranteed long-term maintenance. This is a single-maintainer project; a Laravel 13 bump is a good sign but not a support contract. Have a contingency plan (fork or replace) if invitations are business-critical.
• The invitation flow must be heavily customized (multi-step approval, custom token semantics, non-email delivery channels) — the integration may cost more than a direct implementation.

How to Pitch It (Stakeholders)

For executives: Invitations are a small but unavoidable feature of any product with accounts and teams — every customer-facing admin tool eventually needs "invite your colleague." This package supplies that flow for our Laravel/Filament stack off the shelf, turning a multi-day build into configuration and removing a recurring piece of undifferentiated work from the roadmap. The new release adds Laravel 13 support, which keeps us aligned with the framework's upgrade path rather than blocked by a lagging dependency. The main caveat is maintenance risk: it is a small, single-maintainer open-source project, so we should treat it as a convenience layer, not a critical dependency, and keep the invitation flow replaceable.

For engineering: v2.0.2 is a compatibility release — Laravel 13 support, no feature or API changes indicated. Practical read: it's a low-risk bump, and it tells us the maintainer is responsive to framework majors. Adopt it behind the standard invitation flow (send, accept, assign role), keep our own acceptance/authorization logic where it touches our domain model, and avoid letting the package own anything we'd need to reimplement under pressure. Confirm the Filament major-version constraint before committing, and pin the version explicitly so the Laravel 13 compatibility we're relying on doesn't drift. Budget a short spike to read the source and confirm the invite-acceptance hooks match our tenancy model. If we later need SSO, SCIM, or domain capture, plan to replace rather than extend — that's an identity-platform decision, not a plugin configuration.