Product Decisions This Supports
- Roadmap / platform upgrade sequencing. v2.1.0 is a compatibility release ("add Statamic 5 support"). That single line is the decision-relevant content: it tells you the addon has cleared the Statamic 5 / Laravel 11 era. If your roadmap has a Statamic 4 → 5 migration in the next two quarters, this package no longer needs to be treated as a migration blocker or a "replace vs. rebuild" line item.
- Build vs. buy for user/team grouping. Packages in this category exist to avoid re-implementing group CRUD, control-panel screens, and permission wiring. The buy case is strongest when grouping is a supporting feature (internal teams, agency client accounts, departmental access) rather than a core differentiator. The build case strengthens if you only need a thin
belongs_to-style grouping and no CP UI.
- Feature scoping for multi-tenant or team-based access. This is the kind of addon that lets you ship "organizations / teams / client groups" as a content-model concern instead of custom code — worth weighing when scoping seats, agency hierarchies, or content-ownership models.
- Dependency risk review. A minor version bump for a new CMS major implies the addon stays on a maintained line and that the maintainer is tracking upstream. That's a positive input to your "keep / replace" review for the dependency inventory — but a single-maintainer, single-purpose addon should still carry a documented fallback plan (fork or vendor) in your tech-risk register.
- Non-decision: this release changes no product surface. Do not treat it as a reason to schedule work beyond a version pin and a smoke test.
When to Consider This Package
Adopt it when most of the following hold:
- You are on, or imminently moving to, Statamic 5 (and the Laravel version that implies) — this release is the one that unblocks that path.
- Grouping of users is a real modelling requirement in your domain (teams, agencies, departments, client accounts) and you want it managed in the control panel by editors, not by engineers.
- You are comfortable with a small, focused, single-maintainer addon that sits alongside core Statamic permissions rather than replacing them.
- Your content model is stable and you can absorb an addon upgrade inside a normal maintenance window.
Look elsewhere — or build in-house — when:
- You are staying on Statamic 4 for the foreseeable future; confirm whether v2.1.0 is dual-compatible (4 and 5) or 5-only before pinning, since that determines whether this is an upgrade or a fork point.
- You need group semantics beyond the addon's model (complex role inheritance, per-group entitlements, SSO-driven group sync) — that is application logic and belongs in your codebase.
- You require an actively supported vendor with SLAs, or your policy disallows single-maintainer community packages in the auth/permissions path without a vendoring plan.
- Native Statamic roles plus a simple Eloquent relation already cover your use case; the CP convenience may not justify another dependency.
Diligence before adopting: verify the exact capability set in a short spike (does it manage groups only, or groups plus permission assignment?), confirm the addon's permission surface actually integrates with Statamic's authorization rather than running in parallel to it, and check the maintainer's release cadence across the 1.x → 2.x history.
How to Pitch It (Stakeholders)
For executives (one paragraph): We reviewed a maintenance release of a small Statamic addon that handles user grouping. The only change is support for the current major version of our CMS. The business value is not new capability — it is that this dependency will not block our planned Statamic upgrade. Cost is low, scope is narrow, and the main risk is that it is a single-maintainer package, which we mitigate by keeping it on a pinned version and not building core access logic on top of it. Recommendation: approve as a low-risk dependency, no dedicated budget required.
For engineering (summary): v2.1.0 adds Statamic 5 support with no feature, breaking, or deprecation changes noted; treat it as a compatibility-only minor. Actions: (1) confirm whether 2.1.0 remains compatible with Statamic 4 or is 5-only before adjusting composer.json constraints; (2) run the upgrade in a branch and smoke-test CP screens, group assignment, and any permission checks that read from group membership — compatibility releases are the most common source of silent fieldtype/authorization regressions; (3) confirm the package's authorization path still routes through Statamic's native permissions so we do not end up with two sources of truth; (4) record the fork/vendor fallback in the dependency register. No application code changes expected.