Statamic Delegated Laravel Package

Product Decisions This Supports

• Scoping editorial access by "territory" instead of by role. Delegated lets you bound where in the content tree a user can act, layered on top of Statamic's existing role/permission model. This is the feature that decides whether a single Statamic install can host multiple brands, regions, departments or client accounts without a separate site per tenant.
• Build vs. buy for multi-team content governance. If the roadmap contains "let regional editors manage only their own pages," the alternatives are (a) building custom permission scoping on top of Statamic's authorization hooks, (b) one install per team/brand, or (c) this package. Option (b) is usually the hidden cost driver — duplicated licences, duplicated content, duplicated upgrades — so a $0-marginal-cost addon that preserves a single install is a strong default.
• Auditability as a product requirement, not an afterthought. The bundled audit log of assignments supports compliance-flavoured asks (who could edit what, and when) in regulated, public-sector, healthcare and finance-adjacent content operations. If a deal or a security review is gated on that question, this package answers it without a bespoke build.
• Roadmap timing: safe to adopt on new projects now. v1.0.2 exists specifically because a fresh Statamic install pulls the newest 6.x, and the previous constraint would have forced a downgrade. That removes the "we'd have to pin an old CMS version" objection that would otherwise push a governance feature out of the current cycle and into a later, more expensive one.
• Upgrade sequencing. The release changes nothing about behaviour: no migration, no change to territories, assignments or the audit log. That means adding it to an existing site is a low-risk, no-freeze-window change — useful when you want the capability shipped without claiming a sprint's worth of regression testing.
• Use cases worth prototyping: regional marketing sites with local editors, agency-run client estates, franchise/multi-location content, internal comms with departmental owners, and any content set where "everyone can edit everything" has already caused an incident.

When to Consider This Package

Consider it when all of the following hold:

• You are on Statamic 6.31–6.38 (this release explicitly verifies 6.34–6.38 and permits the whole 6.31–6.38 range). Anything outside that band is unproven by the maintainer.
• Your access-control need is horizontal — "this editor owns this branch of content" — rather than purely vertical role hierarchy. Statamic's native roles/permissions already handle "who can publish"; Delegated handles "which pages."
• You need more than one editorial team on one install, and separate installs would be commercially or operationally worse.
• You need a defensible record of who was granted what, i.e. the audit log is a feature you would otherwise have to build.
• Your team is comfortable with a small, single-purpose addon whose behaviour is deliberately narrow — it restricts; it does not attempt to be a full workflow/BPM engine.

Look elsewhere when:

• You need approval chains, staged publishing or editorial sign-off. Scoping access is not a workflow engine; if the requirement is "two people must approve before publish," that is a different (and possibly multi-package) decision.
• You need per-field or per-entry-type granularity rather than per-territory. Verify against your actual matrix before committing; this is the most common mismatch.
• You are pre-6.31, or already on Statamic 7 / another CMS. The constraint is explicit and narrow; do not assume forward compatibility, and re-check the range at each Statamic minor bump.
• Your access model is external-facing. This governs control-panel editors, not front-end membership or customer-level permissions.
• You cannot absorb the maintenance tail. A package bounded to a CMS minor range means scheduled re-verification work each time Statamic ships. That is small, but it is real, and it belongs in someone's backlog.
• Your governance need is a one-off — a single hand-managed split of two teams can be solved with native roles and a documented convention, with no dependency at all.

On this release specifically: v1.0.2 is maintenance only — wider version constraint, verification across five Statamic minors, control-panel assets rebuilt with no functional delta. There are no breaking changes, deprecations or new capabilities to plan around. It is a green light on compatibility, not a reason to re-architect anything.

How to Pitch It (Stakeholders)

For executives — one paragraph. Delegated lets several editorial teams share one Statamic install while each sees and edits only their own area of the site, with a record of who was granted which area. Commercially, that is the difference between running one platform and running one platform per brand, region or client — the second is where content duplication, licence sprawl and upgrade overhead accumulate. The newly released v1.0.2 is a compatibility release: it widens support to Statamic 6.31–6.38, so a brand-new site can install it without pinning an older CMS. Nothing about how it restricts access has changed, there is no migration, and existing territories, assignments and audit history are untouched. Recommendation: treat it as low-risk and adoptable this cycle, subject to verifying it matches our actual permission matrix.

For engineering — the short version. Single-purpose Statamic 6 addon that adds territory-based content scoping plus an assignment audit log on top of native roles. v1.0.2 raises the constraint to >=6.31.0 <6.39.0, verified against 6.34–6.38; CP assets rebuilt against 6.38 with no behavioural difference (the one UI-kit addition in 6.36 is unused). No migrations, no data changes, no API changes — upgrade is a composer update with no code work. Two things to own: (1) confirm our field/entry-type permission matrix isn't finer-grained than territories allow, and (2) add a recurring task to re-verify the constraint at each Statamic minor release, since the upper bound will lag. If we need approval workflows or staged publishing, that is out of scope for this package and needs a separate decision.