Filament Approvals Laravel Package

Product Decisions This Supports

• Build vs. buy for approval workflows. Approval gates are a recurring, low-differentiation request across internal tools (expense sign-off, content publishing, procurement, discount/pricing overrides, access requests, change approvals). This package lets you buy that capability as a Filament-native dependency instead of spending 2–6 weeks of engineering on a state machine, approver assignment, and audit trail.
• Roadmap sequencing. It de-risks committing to "approvals shipped this quarter" without carving out platform-team capacity. That frees the roadmap slot for the differentiating work and turns a multi-sprint feature into an integration task.
• Scoping the "configurable" bar. The key product decision is whether you need per-record, sequential, internal approval chains (in scope for this package) or branching, parallel, delegation, SLA-escalation workflows (likely out of scope). Adopting this package is an implicit commitment to the simpler model — make that explicit rather than discovering it in sprint 3.
• Buy-vs-build signal from adoption data. 120 stars, 0 dependents, and a release as recent as 2025-10-21. Read: actively maintained, but essentially unproven in production. That supports adoption for internal, reversible, low-blast-radius workflows — not for revenue-critical or compliance-critical paths without a hardening plan.
• Licensing/packaging. MIT means no procurement cycle, no per-seat cost, no vendor negotiation — the total cost is integration plus an ongoing maintenance contingency, which is easy to justify against internal build cost.
• Roadmap input from the gaps. Questions the package likely does not answer out of the box (delegation when an approver is on leave, escalation timers, org-chart-driven approver resolution, external/customer approvers) become a written list of follow-on requirements rather than surprises.
• Reversibility as a decision lever. A thin, Filament-specific package is cheap to wrap behind your own interface and swap later — which lowers the stakes of saying yes now.

When to Consider This Package

Adopt when:

• Laravel + Filament is already your admin stack — this is a UI-layer package, and its value collapses outside that context.
• Approvals are per-record, sequential, 1–3 steps, internal approvers (managers, finance, legal), with an audit trail requirement.
• The team is small and would rather integrate than own a workflow engine; there is no platform team to build one properly.
• You can accept a young dependency: pin the version, wrap it behind your own abstraction, add integration tests, and budget a fork/maintenance contingency.
• Time-to-market matters more than workflow expressiveness for the first release.

Look elsewhere when:

• You need branching, parallel/countersign, conditional routing, delegation, or SLA escalation — that is BPM-engine territory (Temporal, Camunda, or building a real state machine), not a Filament resource decorator.
• Approvals must be driven by external systems or an API-first client — a Filament admin-scoped package won't be your approval API.
• Compliance, audit, or revenue-critical paths where vendor maturity, support SLAs, and a track record of dependents matter. Zero dependents means zero battle-testing; the risk is on you.
• Volume or multi-tenancy at scale, or event-driven integration with downstream systems.
• Your admin UI is not Filament (Nova, custom Blade, Inertia/Vue) — the integration cost advantage disappears.

How to Pitch It (Stakeholders)

For executives (one paragraph): We have a recurring need for approval gates across several internal tools. Rather than fund a bespoke workflow build, we can adopt an MIT-licensed, Filament-native package that covers the standard case — submit, route to approver, approve/reject, audit — in days instead of weeks, at no license cost. It is intentionally not an enterprise workflow engine, so we're scoping it to internal, low-risk approvals and keeping it behind our own abstraction so we can replace it if requirements grow. The trade-off is maturity: it is actively released but has no known downstream dependents, so we treat it as a fast start with a modest maintenance contingency rather than a long-term platform bet.

For engineering: It's a Laravel/Filament package that adds approval state and approver handling to existing resources — no new infrastructure, no separate service, familiar conventions, easy to extend. Two asks: (1) isolate it behind a small internal interface so our domain code isn't coupled to the package's API, and (2) pin the version and cover the approval transitions with tests, since upstream adoption is thin. If we outgrow it, the swap is contained.

The decision being requested: approve adoption for internal approval workflows in this quarter's scope, with the explicit constraint that anything needing parallel routing, escalation SLAs, or external approvers goes through a separate design review.