Filament Intercom Laravel Package

Product Decisions This Supports

• Admin and back-office tooling: build vs buy. A Filament 4-compatible package is a candidate for internal admin surfaces (CRUD screens, approval queues, ops dashboards). The PM decision is whether this package covers the panel needs of the next 1–2 quarters or whether a bespoke Livewire/Inertia admin layer is warranted.
• Framework upgrade sequencing. v2.0.0 landing on Filament 4 is the signal that this package tracks the current major of the Filament ecosystem. That makes it a dependency in the Filament 4 migration workstream rather than a blocker — a PM can place the Filament 4 upgrade on the roadmap without carving out a replacement-spike for this package.
• Roadmap gating for new panel features. If upcoming epics (multi-tenant panels, role-scoped dashboards, custom resources, workflow actions) assume Filament 4 primitives, this release is the enabling dependency. Confirm the package's supported version range before committing those epics to a date.
• Vendor and maintenance posture. A package publishing a major aligned to a framework major is a reasonable signal of active maintenance. Factor that into the "keep vs replace vs fork" decision at the next dependency review rather than treating it as a one-off patch.
• Use cases this typically unblocks: internal ops consoles, customer-support tooling, content/moderation queues, tenant-scoped admin panels, and lightweight internal CRMs — all cases where speed of internal delivery outweighs bespoke UI differentiation.

When to Consider This Package

Adopt when:

• The product surface is internal or low-brand — admin, ops, support — where a component-driven panel is acceptable and bespoke design is not a differentiator.
• The team is already on Laravel + Filament, or is willing to standardise on Filament 4 for panel work. The value proposition collapses if Filament is not the house pattern.
• You need shipped panel functionality now and the package's scope matches the majority of your screens; the remaining 20% is acceptable as custom Filament resources rather than a reason to build from scratch.
• You are planning or mid-flight on a Filament 4 upgrade and want dependencies that do not pin you to Filament 3.
• You want a buy/borrow answer for admin tooling so engineering time stays on customer-facing differentiation.

Look elsewhere when:

• The surface is customer-facing with hard design or performance requirements — panel scaffolding tends to show through.
• The package's Filament 4 support is the only thing in the release. A major version with a single compatibility line says little about feature depth, security posture, or API stability. Get the upgrade guide and breaking-change list from the maintainer before scheduling the bump.
• You are still on Filament 3 with no upgrade budget. A v2.0.0 that jumps majors is likely a breaking change for you; adopting now means funding the Filament migration.
• Bus-factor or licensing is unresolved — single-maintainer packages in the admin path are a continuity risk worth pricing in.
• The functionality is thin enough to be a few resources — a dependency that only saves a day of work is a maintenance liability, not leverage.

How to Pitch It (Stakeholders)

For executives: This is a maintenance and compatibility release, not a feature release — the package now supports Filament 4, the current major of the admin-panel framework we use for internal tooling. The practical effect is that our internal admin roadmap is not blocked by this dependency, and we can proceed with the Filament 4 upgrade on schedule. No new spend, no new vendor; the decision on the table is sequencing, not procurement. Recommend we treat this as part of the planned Filament 4 migration and not as a standalone project.

For engineering: v2.0.0 declares Filament 4 support. Treat it as a major-version bump: expect breaking changes from the Filament 3 line, read the upgrade guide, and pin the version explicitly in composer.json rather than floating. Validate against our panel customisations — custom resources, widgets, and any vendor-published views are the likely breakage points. Test on a branch with the Filament 4 upgrade applied first, then this package, so failures are attributable. Confirm the maintained version range and release cadence before we rely on it for new panel work; if the package's scope no longer matches our screens, flag it at the next dependency review rather than expanding our fork surface.