Laravel Crm Filament Laravel Package

Product Decisions This Supports

• Buy vs. build on the admin surface. The panel remains a Filament UI layer over venturedrake/laravel-crm, not a CRM in its own right. The decision it informs is unchanged: ship a usable back office on core in days, or spend engineering time hand-building Filament resources, filters and board views against the same models. v1.4.0 keeps the buy case intact but changes its terms — the panel now tracks core 2.5.0, so you are not choosing between "a panel" and "a stale panel," you are choosing between "a panel plus a coordinated two-package upgrade" and "your own panel." Budget the coordination, not just the licence.
• Whether to sell into variant-based catalogues. Product variations are the headline product capability. SKU-, barcode- and price-level variants, editable and reorderable on the product form, a variation picker that appears on deals, quotes, orders, invoices and purchase orders, and variation identity carried through quote → order → invoice and order → purchase order. Before this release the panel could not express a catalogue where one product sells in several sellable configurations; you either modelled variations outside core or declined the requirement. This is the release that opens apparel, electronics, parts, subscription tiers and any "size/colour/edition" SKU to the panel. Treat it as a roadmap gate, not a feature bullet.
• Pricing correctness as a revenue risk. Two changes have money attached. The product edit form now loads Product::getPrimaryPrice(), matching core 2.5.0 — previously a product priced only in a non-primary currency loaded blank and saving silently overwrote that price. And a variation without its own price falls back to the product price by design. The first is a data-loss bug now fixed; the second is a deliberate pricing policy that product and finance should sign off on explicitly, because it means an incomplete variation row sells rather than blocks.
• Procurement and margin accuracy on order → purchase order. The panel now uses the variation's own cost row (cost_per_unit, then unit_price) when converting an order to a purchase order. If you price sell-side from a variation and buy-side from a variation, that mapping is now explicit. Relevant wherever margin is computed downstream of the CRM rather than inside it.
• Upgrade cadence and maintenance-cost roadmap. The dependency move from ~2.4.2 to ~2.5.0 reverses the pattern set by v1.3.0: core minor adoption is once again gated on a panel release, and the ceiling is now 2.6. The honest framing for roadmap planning is that patch-level core fixes (2.5.x) still flow without a panel release, but core minors (2.6) require a compatibility pass. v1.3.0 removed per-patch upgrade overhead; v1.4.0 does not restore it for minors. Plan the panel into any core minor budget line.
• Coordinated-release capability as a delivery constraint. v1.4.0 requires ~2.5.0 and must be updated in the same deploy as core — variation data only persists through core 2.5.0's services. That is a deployment-pipeline decision, not just a Composer one: if your pipeline, platform team or change process can't ship two packages atomically, you have a real risk of a panel that writes variation data core doesn't understand. If atomic two-package deploys are hard for you, that is a reason to sequence deliberately rather than a reason to skip the release.
• Deprecation management on a shipped surface. Settings → Product Attributes, ProductAttributeResource, its pages and its crm product attributes permissions are removed, following core 2.5.0. The feature never had a table behind it in core, so no data is lost — but any nav link, bookmark, custom page, support article, role configuration or internal runbook pointing at filament.*.resources.product-attributes.* now breaks. This is a communications-and-cleanup task with a deadline, and it is the kind of removal that generates support tickets if it isn't announced before the upgrade, not after.
• Data-integrity correctness in relationship and order flows. A contact person and an organization saved together on a lead, deal, quote, order, invoice or purchase order are now linked to each other as related contacts, idempotently. Separately, purchase-order line edits now actually save — the previous purchaseOrderLines shim submitted rows core never read in a usable shape, so edits were lost. Both are escalation-class bugs rather than test-class bugs: one produces an org chart that silently disagrees with reality, the other produces a PO the operator believes they corrected. The quote → order conversion that threw on crm_labelables.id is fixed as well, removing a hard failure on a core revenue path.
• Support-cost reduction for hosts that skip Filament maintenance. laravelcrm:filament-upgrade now runs filament:assets, and the installer wires it into post-autoload-dump, so every composer install republishes the stylesheet for the installed Filament version. The observable symptom — resource tables that can't scroll sideways because the content area is pinned at 100vw beside the sidebar on Filament v5 — is a classic "our CRM is broken" ticket with a one-line cause. Worth calling out because it changes the class of ticket your team receives, not just the code.
• Feature parity for regulated / privacy-sensitive customers (carried forward). Field-level encryption remains functional end to end as established in v1.3.0; decryption-aware pickers and PHP-side matching now ship as the baseline on core 2.5.0. Nothing regresses here, and the version floor for encryption-enabled deployments simply moves up to v1.4.0.
• Headless / API-first product variants (carried forward). Connect and Disconnect stay hidden when LARAVEL_CRM_USER_INTERFACE=false, so the integration-only tier remains a supported configuration on the new core baseline. Confirm re-verification against 2.5.0 routes during the upgrade rather than assuming it carries.
• Integration packaging decisions (carried forward, still live). Core's move of dcblogdev/laravel-xero from require to suggest still means updating core silently drops Xero — no error, no failed job, just a stopped sync. The install notice with a copyable command remains, so the dependency is an explicit, ownable line in your composer.json. The Guzzle ^7 cap that comes with it still constrains anything else in your stack wanting Guzzle 8. Re-check this line on every core bump including 2.5.0.

When to Consider This Package

Adopt when:

• You are building on venturedrake/laravel-crm 2.5.0 and want a working Filament panel instead of a blank slate — teams, boards, calendars, quotes, orders, invoices, purchase orders, products, deliveries, activity feeds.
• You need product variations. This is the first release where the panel can express SKU/barcode/price variants, price a line from a variation, carry the variation through quote → order → invoice and order → purchase order, print it on PDFs, emails and the portal, and find a product by a variation's SKU from the products index. If variations are on your roadmap, this is the minimum version and there is no backport.
• You need contact ↔ organization linking to be correct. Saving a person and an organization together on any of the six document forms now creates the related-contact link, without duplicating an existing one.
• Purchase-order line editing matters to you. If users edit PO lines today on 2.4.x, those edits are being discarded; this release is the fix.
• You can take a coordinated two-package deploy (composer update venturedrake/laravel-crm venturedrake/laravel-crm-filament plus php artisan laravelcrm:filament-update) and have checked your navigation, docs and permissions for references to the removed Product Attributes surface.
• You need field-level encryption usable rather than nominally configured — carried forward, still a hard floor for encryption-in-scope deployments.
• You are deploying headless (LARAVEL_CRM_USER_INTERFACE=false).
• You are on or planning Xero and want the integration's absence to be visible rather than silent.

Look elsewhere or wait when:

• You cannot update core to 2.5.0 on the same deploy. The panel requires ~2.5.0; there is no partial adoption. Variation writes depend on core 2.5.0's services, so a mismatched pair is not "slightly degraded," it is incorrect persistence. Wait until the pipeline can ship both together.
• You have customised against the Product Attributes surface. Any custom page, resource, nav item, role config or external link targeting filament.*.resources.product-attributes.* must be reworked first. There is no compatibility shim; the model it was built on is deleted in core.
• You have already built variations yourself. If you modelled variants outside core, this release's variation model is a second source of truth, and you should decide which one wins before upgrading rather than after.
• You are on core 2.4.x and stable. v1.3.0 remains a perfectly good resting point with the encryption and headless fixes. Adopt v1.4.0 for variations, contact ↔ org linking, or the PO line fix — not simply to be current.
• You are on core 2.6 or later, or need to be. The panel caps below 2.6 by design; a core minor waits for a compatibility pass.
• You need Guzzle 8. The Xero package still caps Guzzle at ^7, and the panel can't resolve that for you.
• You need a CRM product, not a panel. Pipeline logic, automation, permissions and reporting live in venturedrake/laravel-crm. Evaluate core separately; adopting the panel is not adopting a CRM strategy.
• You have a mature in-house Filament panel. The individual fixes here — variation-aware line pricing, getPrimaryPrice() on the edit form, idempotent contact ↔ org linking, dropping the purchaseOrderLines shim in favour of the shape core reads — are each portable patterns. The adoption case is weakest if you only want one of them.

How to Pitch It (Stakeholders)

To executives: This release is a capability release with an upgrade tax attached. The capability is product variations: the CRM can now sell one product in several SKUs, each with its own barcode and price, and carry that variation through quotes, orders, invoices and purchase orders — which is the difference between addressing catalogue-based businesses and declining them. Three correctness fixes carry revenue weight: purchase-order line edits now actually save instead of being silently discarded, product prices held only in a secondary currency are no longer blanked out on save, and converting a quote to an order no longer fails. The tax is coordination: the panel and core must move to 2.5.0 in the same deploy, and the Settings → Product Attributes screen is removed because core deleted the model behind it. That removal loses no data — the feature never had a table — but it needs announcing to users and cleaning out of internal links, docs and role permissions before the upgrade, not after. One pricing behaviour needs an explicit product decision: a variation with no price set sells at the product price rather than blocking the sale.

To engineering: Bump both packages together — panel to v1.4.0, core to ~2.5.0 — then run php artisan laravelcrm:filament-update, which chains core's laravelcrm:update and applies 2.5.0's three migrations (variation columns, PO line comments / order_product_id, removal of the crm product attributes permissions). Variation persistence goes through core's ProductService::syncVariations(); removed variations are soft-deleted so existing lines keep their label. The variation picker only renders for products with active variations or lines already on one, changing the product clears it, and conversions map it through — order → PO reads the variation's cost_per_unit then unit_price. The purchaseOrderLines shim is gone; PO edits now submit the products rows PurchaseOrderService::update() actually reads, so audit any code that referenced the old property. Product edit now uses Product::getPrimaryPrice(); the previous blank-load-and-overwrite path is closed. Contact ↔ org linking is called from the panel's pages because core makes that call in its Livewire components rather than its services — keep that divergence in mind when comparing behaviour against core. The quote → order label copy now plucks the label id rather than the non-existent crm_labelables.id. Finally, laravelcrm:filament-upgrade now runs filament:assets and is hooked into post-autoload-dump, so Filament stylesheets republish on every install — the v5 sideways-scroll breakage from a stale first-install stylesheet should not recur, but verify on hosts with pinned or customised asset pipelines. If Xero is live, confirm dcblogdev/laravel-xero:^1.1.3 is still in your own composer.json after the core bump; still no error if it isn't, the sync just stops, and the Guzzle ^7 cap still applies.

To security and compliance reviewers: Field-level encryption remains functional on this baseline: with encrypt_db_fields enabled, contact and organization pickers and title search decrypt and match in PHP rather than relying on SQL LIKE against ciphertext, and with encryption off search still runs in SQL. That behaviour is carried forward unchanged from 2.4.6 parity and the version floor for encryption-enabled deployments is now v1.4.0. Two items need review in this release. First, the crm product attributes permissions are removed by core 2.5.0's migration — audit role definitions and permission matrices for references before upgrading, since a permission that disappears from the registry can fail open or fail loudly depending on how your authorisation layer resolves unknown abilities. Second, two integrity fixes change stored relationships: saving a contact person and an organization together now creates a related-contact link between them (idempotent, no duplication), and clearing a contact or organization on a quote, order, invoice or purchase order continues to unlink rather than retain the association. Expect existing records not to have links that a re-save would now create; if your reporting assumes full contact ↔ organization coverage, backfill or re-save rather than assuming the fix retroactively repairs history. Product variation records now carry SKU, barcode and price and are subject to the same data-handling classification as product data generally — confirm they are covered by your retention and export procedures.