Custom Role: Edit Initiatives Without Cascading Workspace Permissions

What is the challenge?

Aha!'s permission model cascades down the workspace hierarchy — granting a user Contributor-level access at a higher layer (e.g., Operating Plan or Workspace Line) in order to let them edit Initiatives at that layer also grants that same Contributor access to every nested Workspace Line and Workspace beneath it. There's currently no way to scope edit permissions to Initiatives at a specific hierarchy level without also opening up full content access to everything nested below.

What is the impact?

This forces a binary choice that doesn't fit how initiative ownership actually works: either under-provision (Viewer/Reviewer access, which can't edit Initiatives at all) or over-provision (full Contributor rights cascaded into workspaces the person has no reason to touch). Over-provisioning creates governance and audit exposure — it becomes harder to reason about who can edit what, and license/permission audits get more error-prone the more inherited access exists. It's also a structural blocker to enabling more distributed initiative ownership — for example, giving portfolio or program leads edit rights at the Operating Plan layer — without inadvertently exposing every downstream workspace's content.

Describe your idea.

Add ability to scope custom role to grant Initiative-edit permissions at a specific level of the hierarchy — Operating Plan or Workspace Line — without inheriting Contributor-level access into child Workspace Lines or Workspaces. In effect, an "Initiative Editor" role that stops at the initiative layer rather than cascading full workspace content permissions downstream. This would let admins grant edit access that matches the actual scope of a person's responsibility (initiative-level coordination) instead of defaulting to full nested access.