- What does tapp/filament-invite do?
- It is a Filament panel plugin that adds invitation-based user registration to your admin panel. An admin triggers an invite action on your User resource, the package emails a signed registration URL, and the invitation is tracked as pending until the invited person accepts. It is a focused vertical slice for back-office account provisioning, not a replacement for Fortify, Breeze or Jetstream registration.
- How do I install tapp/filament-invite?
- Run composer require tapp/filament-invite, publish the config and migrations, then run php artisan migrate. Add the package trait or interface to your User model and wire the invite action into your Filament User resource. A competent Laravel developer should reach a working demo in under a day, with most effort going into transactional mail, SPF/DKIM/DMARC and queue workers rather than code.
- Which Laravel and Filament versions does tapp/filament-invite support?
- The package targets PHP 8.1+, Laravel 10 through 12, Filament v3 and above, and Livewire, sitting on the TALL stack without adding a new runtime or SaaS dependency. Because Filament changed its action and plugin APIs between v3 and v4, pin both the package and Filament to constraints you have actually tested in composer.json. Check the repository's composer.json and release history for the current stated support window before committing.
- Does it conflict with Fortify, Breeze or Jetstream registration routes?
- The acceptance flow exposes a public, unauthenticated route, so confirm it does not shadow or collide with your existing registration or password-reset routes. The package does not own identity and does not replace Fortify, Breeze or Jetstream, so both flows can coexist if namespaces and middleware are checked. Test the acceptance URL against your existing auth routes before shipping.
- Where does tapp/filament-invite store invitation state?
- Invitation state is stored either as columns added to your users table or in a separate invitations table, so verify which approach the published migration uses before building on it. Published migrations become yours forever, so review them and avoid edits that a future package upgrade would conflict with. Decide on a single source of truth for account status and do not let package columns diverge from your own status or deactivated_at fields.
- How are invite links secured, expired and revoked?
- Signed URLs are the right primitive, but token expiry, single-use enforcement, revocation on resend and invalidation on user deletion are things to verify rather than assume. Test resending an invitation to the same address and confirm the previous link stops working. Also ensure signed invitation URLs are never logged with their signatures intact, since email invite links are a phishing-adjacent surface.
- Is the invitation email queued, and can I customize the template?
- The package sends invitations through Laravel notifications with a Blade mail template. Whether the notification is queued depends on configuration, so add ShouldQueue or run a queue worker and confirm sends are throttled. You should be able to override the mail template and localization strings by publishing the package views and lang files; verify that before designing your own branding.
- Does it support role assignment and Filament multi-tenancy?
- The package does not own identity or authorization, so role assignment at invite time, including integration with spatie/laravel-permission, is likely manual work on acceptance. Confirm whether the action respects Filament's multi-tenancy and panel scoping or is registered globally, and gate who may invite whom with policies. In a multi-tenant panel, an admin in one tenant must never be able to invite into another.
- How do I handle existing users or re-inviting an email?
- This is the most likely source of production incidents, so define behavior when the address already belongs to an active, soft-deleted, deactivated or pending user. Backfill existing accounts as accepted so the UI does not offer invites to people who already have accounts, and retire any manual create-user-and-set-password workflow in the same release. Two competing provisioning paths are worse than either one alone.
- Is tapp/filament-invite production-ready, and what is the maintenance risk?
- Weigh the adoption signal: the package is small, single-vendor and early in its lifecycle, with little ecosystem evidence that it survives a Filament major-version bump. For internal admin panels the risk is manageable if you pin versions, keep the acceptance flow thin and review migrations as your own code. For customer-facing self-serve onboarding, a dedicated invitation service or your existing identity provider is usually the safer fit.