Hi community,
Transparency is important but not all work is meant for everyone to see. Some work needs a smaller audience, like confidential strategies, sensitive initiatives, or simply an idea you want to refine before sharing it widely.
To support that work, we're rolling out restricted goals, so you can limit an individual goal or project to specific people, so sensitive work gets tracked properly without being visible to everyone. Restricted goals and projects use the same Can view and Can edit permission levels you already know, so there isn’t a new permission model to learn.
Goals are never islands. They connect upward to parent goals, downward to children, and across shared metrics and progress. Restricting one has a ripple effect across the entire hierarchy, so access is managed at that level.
Restricting a goal restricts everything under it. Sub-goals, key results, and metrics are all restricted along with it, and they share the same access. Anything you add later is automatically restricted too.
Access is shared across the hierarchy. Changing someone's access on a sub-goal applies to the parent goal and every other goal in the hierarchy.
You can change your mind at any time. Goals can be switched between open and restricted in both directions. Set it when you create the goal, or change it later.
Linking is limited to the restricted hierarchy. You can create new sub-goals and key results directly on a restricted goal, but you can't link an open goal in, or link a restricted goal onto an open one.
Metrics stay inside the hierarchy. Metrics created on a restricted goal can't be reused on an open goal.
Those last few constraints exist for the same reason: progress and updates roll up between linked goals, so allowing restricted goals to link out would leak restricted detail to people without access.
We've also updated the naming and changed how access works on projects. Private projects are now called restricted projects, aligning the terminology with other Atlassian apps. If you've used private projects, this will feel familiar. You can switch a project between open and restricted at any time from the Share dialog.
Restrictions are respected everywhere. Restricted work is honored across Jira, Confluence and Focus, and it won't surface in the Atlassian Data Lake or Atlassian Analytics.
Every change is tracked. All access changes – including restricting, opening, and adding or removing people – appear in the item's activity history. Admins can also review access changes in the Atlassian audit log.
Admins don't get implicit access. Unlike open goals and projects, site and app admins won't automatically see restricted items. We didn't want administering the apps to mean automatic access to confidential work.
Anyone with Can edit access can add or remove people and change the item's access.
Your existing goals and projects keep their current access. There’s nothing to change. Restricting is opt-in, item by item, whenever you need it.
We've started to roll out this update, so you should expect to see this in your instances in the coming week.
Have a play, and let us know what you think in the comments. If you hit anything odd, or you have use cases we should be designing for, we'd like to hear about them. Thank you for your feedback and thanks for being part of the Goals and Projects community!
Nicola Sun
3 comments