As with Initiative-editing, granting a user Contributor-level access at a higher hierarchy layer (Operating Plan or Workspace Line) in order to let them create or edit Roll-Up Releases at that layer also cascades that same Contributor access into every nested Workspace Line and Workspace beneath it. There's no way to scope create/edit permissions to Roll-Up Releases specifically without also granting full content access to everything nested below. This is especially problematic for very large organizations.
This creates the same binary trade-off as with Initiatives: under-provision (no ability to manage Roll-Up Releases at all) or over-provision (cascaded Contributor rights into workspaces the person has no functional reason to access). This is particularly relevant as we move towards standardizing the release hierarchy pattern (Initiatives (Workstreams) > Roll-Up Release > Releases) — the more that pattern becomes the standard, the more people will need release-level edit rights at a rollup layer without needing, or being entitled to, edit rights on every underlying workspace's content.
Add ability to scope custom role that grants create/edit permissions for Roll-Up Releases at a specific hierarchy level, without inheriting Contributor-level access into child Workspace Lines or Workspaces. This would let admins assign release-management responsibility that matches actual scope of ownership, consistent with the same principle as scoped Initiative-editing access.