Laravel Crm Laravel Package

Product Decisions This Supports

Retention and engagement tooling is now in-scope — decide whether to use it or build it. v2.2.7 adds a notifications feature. This is the kind of capability that typically gets specced as a separate initiative ("alerting", "digest emails", "in-app inbox"). Its presence in the package means the retention/engagement workstream can be scoped as configuration and UX rather than net-new engineering. The product decision is not "should we notify users" but "do we adopt the package's notification model or does our engagement strategy need something it cannot express."

Search is being positioned as a primary navigation surface, not a filter. Mega search now works inside a modal and shows per-section record counts. Per-section counts are a small feature with outsized product value: they answer "is this data even in here?" before the user commits to a query, which is the difference between a search that feels trustworthy and one users abandon. If discoverability is a known complaint or a support-ticket driver, this release is a direct lever — and it argues for treating the package's search as the product's search rather than building a parallel one.

Quotes in Quick Add signals a sales-workflow surface worth mapping against your roadmap. This is the second consecutive release touching CRM-adjacent primitives (leads, people, products, now quotes). If quoting or sales-pipeline work is anywhere on the roadmap, verify overlap before scoping it — the package may already cover the create-path. Conversely, if you are not a sales-workflow product, this and the lead/person fixes are noise.

Dashboard data filtering (#2605 previously, refined here) continues to be a configurable product lever. Combined with the earlier configurable date ranges, the dashboard is drifting toward self-serve segmentation — which determines whether one deployment can serve multiple customer segments or whether you need per-segment customization.

Search result quality fixes (lead/product, person form) indicate the data-entry layer is actively maintained. Bug fixes on create/update paths are the least glamorous but most decision-relevant signal: it means the maintainer is responsive to real usage, which lowers the long-term ownership risk of depending on this package for core CRUD.

Security is now a recurring line item, not a one-off. v2.2.6 shipped a security fix (#2641); v2.2.7 ships another ("Improved in Security") with no detail. Two consecutive releases with security content changes the calculus: this is a dependency that requires a standing patch cadence, not an ad-hoc upgrade when convenient. Budget for it.

Unchanged from the prior assessment and still live: Japanese and Chinese locale support (v2.2.6), PDF export for dashboard reports (#2640), MariaDB support (#2665). None of these are superseded by v2.2.7.

When to Consider This Package

Adopt or upgrade when:

• It is already a dependency. Second security-adjacent release in a row; there are no breaking changes flagged, so the cost of upgrading is low and the cost of drifting is cumulative. Upgrade.
• Notifications are on your roadmap as an engagement, alerting, or digest feature. Evaluate the built-in model before writing a spec — but validate it against your channel requirements (email, in-app, webhook) first.
• Search discoverability is a known pain point. Mega search with per-section counts is a credible answer to "I can't find the record," and it is cheaper to adopt than to build.
• You need localized admin/dashboard surfaces for Japanese- or Chinese-speaking users (carried from v2.2.6).
• Stakeholders require scheduled or on-demand exported reports (PDF) rather than live dashboards (carried from v2.2.6).
• Your infrastructure standard is MariaDB, or you are evaluating it (carried from v2.2.6).
• You are scoping a reporting or search build and would otherwise spend engineering time on plumbing.

Look elsewhere or defer when:

• The release notes are the only artifact you have. "Resolved Issues" and "Improved in Security" are not actionable specifications. Before committing, you need the actual diff, changelog, or advisory — you cannot assess exposure or regression risk from these notes alone. This is the single biggest caveat in v2.2.7.
• You need a reporting surface beyond dashboards — embedded analytics, ad-hoc query builders, warehouse-scale aggregation. Out of scope; evaluate a dedicated BI layer.
• PDF export fidelity is a hard requirement (branded templates, multi-page layouts, accessibility tagging). Verify actual output against the design spec; package exports typically cover the 80% case.
• You need rich, multi-channel notification orchestration (routing rules, user preference centers, delivery guarantees, templating). Package notifications are usually a sensible 80% and a poor fit for the last 20%.
• You are not a CRM or sales-workflow product. Quotes, leads, and person forms are domain-specific; the value here is narrower than the headline feature count suggests.
• You are mid-freeze or mid-release. No breaking changes are declared, but given two consecutive security-touching releases, schedule the bump immediately after the freeze rather than skipping it.

Before committing, confirm:

• Security severity and exposure — what "Improved in Security" actually changed, and whether it affects your configuration.
• Migration and infrastructure impact of notifications — new tables, queue workers, mail transport, and whether channels are configurable or hardcoded.
• Whether mega search requires indexing, a search driver, or reindexing on upgrade, and how per-section counts behave at your data volumes.
• Whether the dashboard data-filter change alters saved filters or user-configured views (silent behavior change risk for existing users).
• That the package's security cadence matches your patch SLA — two security-relevant releases back to back means you need an owner and a window, not a backlog item.
• Locale quality (machine-translated strings are a real risk) and whether PDF export is free-tier or a paid add-on.

How to Pitch It (Stakeholders)

For executives (one paragraph): Version 2.2.7 of our Laravel dashboard package is a feature release with another security improvement, and it is a straightforward approval. It adds a notifications capability that would otherwise be a separately budgeted engagement initiative, upgrades search into a proper modal experience with per-section result counts so users can see what data exists before they query, and adds quoting to the quick-create flow — relevant if we pursue sales-workflow functionality. It also includes another security improvement, following the fix in the previous release, which means this dependency now needs a routine patch cadence rather than occasional attention. No breaking changes are reported. Recommendation: approve the upgrade, schedule it right after the current freeze, and treat notifications and search as previously unbudgeted scope we no longer need to build — with the caveat that the release notes are thin, so engineering should confirm the security and migration details before we commit to a date.

For engineering (short brief): Upgrade to v2.2.7. Priority order: (1) determine what "Improved in Security" changed — request the diff or advisory, since the notes give us nothing; this is now the second security-touching release in a row and we should assume a standing patch cadence. (2) Assess the notifications feature for migration, queue, and mail-transport impact before enabling it anywhere — confirm whether channels are configurable and whether it ships enabled by default. (3) Mega search in a modal with per-section counts: check whether it needs a search driver, index, or reindex at our data volume, and whether it replaces or duplicates existing search paths. (4) The dashboard Data Filter update may change behavior for users with saved filters — verify and flag to QA for snapshot/e2e updates. (5) Quotes in Quick Add, plus the lead/product and person-form fixes (#2682, #2680), are contained changes but touch create/update paths — worth regression coverage. No breaking changes declared; verify against our pinned version and run the suite. Carried and still unadopted from v2.2.6: ja/zh locales, PDF export (#2640), MariaDB support (#2665) — no action required unless those become priorities.

Key caveat to surface at both levels: the v2.2.7 notes are unusually thin — "Resolved Issues" and "Improved in Security" name no issues and no severity, and the feature list gives no indication of breaking surface, migrations, or opt-in defaults. Treat the upgrade as approved in principle but gated on engineering reading the actual diff. The security item should not wait on roadmap prioritization; the feature adoption decisions can.