Filament Change Requests Laravel Package

Technical Evaluation

Architecture fit

• Filament-native approval/workflow plugin for Laravel admin panels. Fits only applications already running a Filament panel; no value for API-only, Inertia, or Blade-custom admin surfaces.
• Enforcement model is opt-in at the page level via SubmitsChangeRequests / SubmitsCreationRequests traits. Any resource page that does not adopt the trait silently bypasses the approval workflow — the control is cooperative, not global. This is the single most important design fact for a TPM: "approval required" is a per-page configuration decision, not a platform guarantee.
• v1.0.0 explicitly targets Filament 4 and 5, Laravel 12.4+/13, PHP 8.3+. That is a very recent floor across all three axes, which narrows the addressable install base and signals the package is tracking upstream majors closely rather than supporting a long tail.
• Authorization is a clear four-stage chain: self-review blocked by default → authorizeUsing() → reviewChangeRequest gate → model policy. Layered and defensible for segregation-of-duties, but four overlapping hooks means the effective decision is hard to reason about without deliberate documentation.

Integration feasibility

• Low-friction install path (composer require, README, presumed publishable migrations/config), but the README is the only integration reference cited — no mention of published config surface, events, or extension points.
• Held-creation linking to the created record on approval is a genuinely useful behavior and reduces post-approval reconciliation work.
• Bulk approve/reject is table-stakes for reviewer throughput and its presence at v1.0.0 is a positive maturity signal.

Technical risk

• v1.0.0, single maintainer, immediate dependency on the newest Filament/Laravel majors → moderate-to-high supply-chain and upgrade-churn risk.
• No stated concurrency control between submission and approval. If the underlying record changes while a request is pending, approving a stored diff may silently overwrite newer state. This is the top functional risk.
• Sensitive-attribute masking is described for the diff view only; unclear whether sensitive values are redacted at rest in the change-request table. Storing pre-image values of PII/credentials in a workflow table creates a new data-residency and retention obligation.
• Rollback semantics are undefined (does it create a compensating change request, or mutate in place?), which matters for audit defensibility.

Key questions

• Is a pending change applied as a diff replay or a full snapshot, and is there an optimistic-concurrency/version check at approval time?
• Are sensitive attribute values masked/encrypted at rest, or only in the rendered diff?
• Is rollback itself auditable and itself subject to approval?
• What events/hooks are dispatched on submit/approve/reject for notifications and SIEM export?
• Does the plugin scope change requests per tenant in multi-tenant panels?
• What is the retention/purge policy for resolved change requests, and are old rows indexed?
• What happens to pending requests when the target record is deleted or soft-deleted?
• Can approvals be performed outside the UI (artisan/API) for automation and break-glass?

Integration Approach

Stack fit

• Hard gates: Filament 4 or 5, Laravel ≥12.4, PHP ≥8.3. Confirm the panel's actual Filament major before anything else — supporting both majors does not mean identical behavior.
• Best fit: internal ops/back-office panels where non-technical staff edit records that need a second pair of eyes (pricing, entitlements, customer records, config).
• Poor fit: high-throughput write paths, customer-facing flows, or anything needing sub-second edit latency.

Migration path

• Publish and run migrations for the new change-request table(s); register the plugin on the target panel; apply the page traits to the resources you intend to gate; wire the reviewChangeRequest gate and per-model policies.
• Sequence the pilot on one low-risk, low-volume resource. Existing in-flight edits are not retroactively captured, so pick a quiet change window.
• Decide explicitly which resources are out of scope — the opt-in trait model makes the exclusion list as important as the inclusion list.

Compatibility

• Pin exact versions in composer.lock; test the Filament major you actually run.
• Anticipate overlap with existing audit/versioning packages (e.g. activity log, model versioning) — you may end up with two parallel histories of the same record and two competing "who changed what" answers.
• Verify interaction with soft deletes, model observers, and any existing saving/saved hooks on gated resources.

Sequencing

1. Version and PHP sanity check; branch install.
2. Publish config/migrations; stand up in staging.
3. Enable on one resource; define reviewer roles and the approval matrix.
4. Validate diff fidelity, masking behavior, rollback, and the self-review block with real data.
5. Roll out resource-by-resource; add the pending-count badge and widget once volume justifies them.
6. Add notification/escalation wiring and retention jobs.
7. Publish an internal runbook before general availability to editors.

Operational Impact

Maintenance

• Single-maintainer dependency at v1.0.0 with a bleeding-edge version floor: budget for occasional upstream breakage on every Filament/Laravel bump, and accept the possibility of forking or patching in-house.
• The four-stage authorization chain is the most likely thing to drift as policies evolve; treat it as code that needs owners and tests, not configuration.

Support

• No commercial support indicated; GitHub issues are the only channel. Escalation for a broken approval path is business-critical, so maintain an internal break-glass procedure (manual DB correction or direct model update) and document it.
• Support load will shift, not vanish: users move from "my save failed" tickets to "why is my change still pending" tickets.

Scaling

• The change-request table is append-only and unbounded; without a retention/purge job and proper indexes it becomes the largest table in the schema and the slowest page in the panel.
• The navigation badge issues a pending-count query on panel render — cache and invalidate, or it becomes a per-page-load tax.
• Bulk approve executes N record mutations in a single request; on large selections this is a timeout and partial-failure surface. Cap batch size and confirm atomicity behavior.
• Diff rendering cost scales with record width (long text/JSON fields); masking large blobs adds render overhead.

Failure modes

• Silent bypass: resource page without the trait remains unapproved — the highest-impact failure and the hardest to detect.
• Stale approval: diff applied over data that changed after submission, with no conflict prompt.
• Dangling requests: record deleted or soft-deleted while a request is pending; unclear whether the request is orphaned, auto-rejected, or errors on approve.
• Queue stall: no escalation path if a reviewer is unavailable; approvals pile up invisibly.
• Partial bulk approval: some records committed, some failed, with no stated compensation.
• Rollback ambiguity: a rolled-back approval that was itself later edited, producing an inconsistent history.
• Data exposure: pre-image values of sensitive attributes persisted in the workflow table beyond their intended lifecycle.

Ramp-up

• Engineering: roughly half a day to a day per gated resource including policy work and staging validation; add time for masking and retention design.
• Editorial users: a real behavior change — "Saved" becomes "Submitted for approval." Plan a short training note and a visible pending state per user, or the first week will generate confusion tickets.
• Reviewers: define who reviews what, expected turnaround, and delegation before enabling the badge, otherwise the pending count becomes noise rather than signal.