Symfony Forestadmin Laravel Package

Product Decisions This Supports

• Admin/back-office build-vs-buy: Forest Admin's Symfony agent (v1.2.0) gives an operations/admin panel on top of an existing PHP backend without building CRUD, filters, and permissions from scratch. Relevant to any roadmap decision to buy an admin layer instead of staffing a team to build it.
• Feature feasibility for internal tooling: The headline of v1.2.0 — native query support in capabilities — moves Forest Admin from "CRUD over your models" to "run arbitrary/native database queries from the admin panel." This unlocks reporting, ad-hoc analysis, and complex joins that previously required a separate BI tool or custom endpoints.
• Roadmap sequencing: If the product roadmap includes internal dashboards, ops consoles, or data-exploration surfaces, this raises the ceiling on what can be delivered through the admin layer without new backend work.
• Use cases this enables directly: custom reporting screens, cross-table aggregation, support/ops lookups needing joins, and migrations where legacy data lives outside the ORM's clean model graph.
• Ecosystem fit caveat: This release is for the Symfony agent, not a Laravel-specific one. For a Laravel/PHP codebase, treat it as evidence of platform direction (Forest Admin is investing in native query capability across its PHP agents) rather than a drop-in dependency — verify the Laravel/Doctrine or Laravel agent path separately.

When to Consider This Package

Consider it when:

• You have an existing PHP backend (Laravel or Symfony) and need an internal admin/ops panel fast, with role-based permissions and audit trails.
• Your team is fielding recurring "can you pull this data?" requests that need joins and aggregates, not just model listing — the v1.2.0 native query capability is the deciding factor here.
• You want to keep admin surface area out of your customer-facing product codebase and off the main product roadmap.
• You need a buy/extend decision resolved in weeks, not quarters.

Look elsewhere when:

• Your team is Laravel-native and unwilling to run a Symfony-ecosystem agent or maintain a bridging layer — validate the Laravel agent's maturity before committing.
• You need a fully self-hosted, zero-vendor-dependency admin layer; confirm licensing, hosting, and data-egress terms for your environment.
• Your data access needs are simple CRUD with no reporting/join requirements — a lighter in-house scaffold may be cheaper to own.
• The native query feature is the whole value proposition and your security posture forbids arbitrary SQL execution from an external admin surface — in that case, gate it behind strict capability scoping or defer.

Diligence items before adoption: confirm how native query capabilities are permissioned (who can author/execute queries), whether queries are audited, and whether row-level scoping applies to raw queries the same way it does to model-based views. This is the main risk introduced by v1.2.0.

How to Pitch It (Stakeholders)

To executives: Forest Admin's latest release (v1.2.0) adds native query support to its admin panel agent. Practically, this means the internal tools layer can now answer complex data questions — joins, aggregates, custom reports — that previously pushed us toward a separate BI purchase or custom engineering work. It strengthens the case for buying the admin layer rather than building one: one vendor covers both day-to-day operations and ad-hoc reporting, with a smaller internal footprint.

To engineering: v1.2.0 is a feature addition, not a breaking change — low migration risk. The new capability is native query execution within the Forest Admin capability set, which expands what admin users can do outside our ORM's model boundaries. Two things to validate before we lean on it: (1) this is the Symfony agent, so we need to confirm parity on our actual Laravel stack; (2) native query execution needs explicit permission scoping and audit coverage so raw queries can't bypass the row-level rules we apply elsewhere.

Recommended next step: run a short spike — stand up the agent against a non-production replica, exercise the native query capability with a real reporting use case, and document the permission/audit behavior. That gives us a defensible build-vs-buy recommendation rather than an opinion.