Escalated Filament Laravel Package

Product Decisions This Supports

• Mandatory security upgrade decision: v1.4.0 closes a real authorization gap — agentGate() / adminGate() were documented but not enforced, leaving most Escalated panel resources open to any signed-in panel user. Treat this as a security release, not a routine feature bump.
• Access-model design: Decide which roles map to escalated-agent vs escalated-admin, whether the plugin uses default gate names or custom ones, and how host-app policies layer on top of the panel gates.
• Tenant-readiness decision: In tenant mode, panel access, API token owner selection, and skill agent selection now require a staff seat in the current account via StaffAccess. This supports multi-tenant SaaS support use cases but requires a tenant seat model to be in place before rollout.
• Upgrade sequencing: The release requires escalated-dev/escalated-laravel ^1.9.0, which brings its own frontend, migration, attachment, guest-access, inbound-email, and tenant-staff-seat changes. PM decision: budget a coordinated upgrade, not an isolated plugin bump.
• Support-operations readiness: Before deployment, verify support staff pass the configured gates. Users who pass neither gate will receive a 403 and lose Escalated navigation, so rollout needs a pre-flight access audit and a rollback/communication plan.
• Build-vs-buy: If the product needs a Filament-based support panel with tickets, canned responses, KB, macros, automations, reports, and tenant-aware staff access, this package is increasingly viable to buy/assemble rather than build — provided the team accepts the escalated-laravel dependency and its upgrade cadence.

When to Consider This Package

• Consider it when: the product is a Laravel app using Filament, needs an internal or customer support panel, and can adopt gate-based authorization (escalated-agent / escalated-admin or custom names) as the access-control boundary.
• Consider it when: the team wants tickets, canned responses, a support dashboard, KB articles, API tokens, roles, automations, macros, skills, custom fields, newsletters, and reports in one panel rather than stitching together separate tools.
• Consider it when: multi-tenant support is required and the host app already has — or is ready to add — tenant-local staff seats through TenantResolver::isAgent/isAdmin; v1.4.0 makes seat checks part of panel access and picker behavior.
• Consider it when: the team can absorb coordinated dependency upgrades. This release requires escalated-laravel ^1.9.0 and points to that release’s migration and frontend changes.
• Look elsewhere when: the product is not on Filament, needs a heavily custom authorization model that cannot be expressed through host gates plus model policies, or cannot tolerate a breaking access-control rollout that can 403 existing panel users.
• Look elsewhere when: the team needs only a simple contact form or shared inbox and does not need the broader Escalated resource surface; the dependency and upgrade overhead may outweigh the value.
• Look elsewhere when: tenant mode is required but there is no reliable tenant staff-seat concept; v1.4.0 will refuse globally flagged users who lack a seat in the current account.

How to Pitch It (Stakeholders)

• To executives: This release fixes a security-relevant access-control gap. The panel’s documented agent/admin gates are now actually enforced, so support staff see only what their role permits. It is a mandatory upgrade for deployed instances, but it carries rollout risk: users without the right gates or tenant seats will lose access until configured.
• To engineering: v1.4.0 enforces agentGate() / adminGate(), adds Support\StaffSeat and Support\PanelAccess, and requires escalated-laravel ^1.9.0. Tickets, canned responses, and the support dashboard require the agent or admin gate; all other Escalated resources and pages require the admin gate. Existing model policies still apply, and tenant mode additionally requires a staff seat in the current account. Plan the dependency upgrade and gate audit before deploying.
• To support operations: Before upgrade, confirm every support user passes the configured agent or admin gate and, in tenant mode, has a staff seat in the accounts they support. Otherwise they will get a 403 and see no Escalated navigation. The API token owner picker and skill agent picker will only list seated agents, which is safer but may change existing workflows.
• To security/compliance: This is a positive control improvement: previously open resources such as webhooks, API tokens, roles, automations, macros, skills, custom fields, KB articles, newsletters, reports, and settings are now gated. Document the gate mapping and tenant-seat requirement as part of the access-control baseline.