Atlassian Projects and Goals access management is now available!

[#1]

We’re excited to announce that you can soon control who can access Atlassian Goals and Atlassian Projects!

Like other Atlassian products, product access to Goals and Projects will be managed in Atlassian Administration. You can give a user or group access to both Goals and Projects, or only one.

A user who has access is allowed to view, create, and update goals or projects and browse their respective directories. A user who doesn’t have access is not able to do any of the above.

We’re rolling out to a small number of sites in early access first. Then, throughout January, we’ll roll out to all other customers who are using Goals and Projects.

If you have any questions or feedback please leave them as comments below and we’ll do our best to address them!

A note for Atlas customers

Enabling the ability to control product access for Goals and Projects allows us to start migrating Atlas customers to the new Goals and Projects experiences. We’ll notify admins before this happens to provide more information. Read our previous Atlas announcement to learn more

[Lai_ Ssu-Yuan _賴思元_]

Great to see this feature being released! 🎉 It’s definitely helpful for us!

I’m wondering if there are any plans to support access control for a single Project or a single Goal in the future? I believe some teams might also prefer more granular, item-specific management.

[Filipe Vítor]

I assumed the purpose of this feature was to allow users to control who could view or manage specific goals or projects. Is that also possible now?

[Nir Nikolaevsky]

Hi @Lai_ Ssu-Yuan _賴思元_ @Filipe Vítor, 

This feature was specifically implemented to help admins control project and goal access on the site-level.

We're also looking at improving the access management of specific projects and goals but that will likely be worked on throughout the year.

Note that we do have private projects. Only users who are added as contributors or followers can view private projects. The work I've mentioned above will improve and expand this functionality. 

Can you tell me more about why you want project and goal specific controls and how you'd use them? Also, if you're open to chatting about this please send me your preferred email to nnikolaevsky@atlassian.com and I'll reach out when we conduct customer interviews.

Thanks and happy holidays! 

[Dirk Lachowski]

@Nir Nikolaevsky 

Note that we do have private projects. Only users who are added as contributors or followers can view private projects. The work I've mentioned above will improve and expand this functionality.

While this is good to know, it would be much more important to have private goals, eg. for financial goals. Any plans for that?

[Jean Gordon]

How can this be removed as we dont allow access across projects but you added and automatically applied.

[Darrel Jackson]

Disappointed that read-only vs. read-write roles haven't been implemented.

The use case is Goals for organisational strategy. We'd have a large number of read-only users (i.e. the whole company) but only a handful of read-write users (i.e. the corporate strategy team).

Also disappointed that deny-by-default private goals haven't been supported i.e. you need to be explicitly invited to the goal to be able to read/update it.

The use case is many goals are commercially sensitive - both in terms of the goal and the updates posted against the goal. You'd only want certain people to have access e.g. execs, account teams.

[Stijn Veer, van der]

Great first step. What would make this perfect is differentiating betweet read and write acces. We don't want everyone being able to create new goals. This would make Goals very messy for the organizational goal structure. 

[Stephen Neil]

There will be great appetite in our org for using goals however I know our exec team won't accept use until read/write access and goal-level access control is a reality. Watching these development with interest.

[Harrison Ponce]

Great update!

I know this was standing in the way of Atlas customers being migrated to the experience. Is there a date or time period when we can expect that transition rolling out? We're very eager for this move!

Also, is the ability to switch a project or goal's visibility between public and private on the roadmap? Sometimes my clients are starting one out and pick the wrong privacy option and they are unable to change it later without recreating the whole thing and archiving the old one.

[Hailin_Zhang]

Hi,

We are using the old user management page and noticed some strange behaviours with this Goals/Projects permission control. 

1. Enabling user's Jira access will automatically grant access to Goals and Projects.

2. Revoking Goals or Projects or Jira access removes all the 3 access.

3. Goals and projects access can be enabled individually without automatically granting other access.

Is this intended design for the permission control?

[Greg D]

As others mentioned, hoping we get a simple privacy toggle that exists both at creation and after creation on all "Projects" (confusing name as mentioned here) and Goals (currently no way to restrict individual goals and can only do that for projects at creation). Need to be able to lock visibility to owner/contributors at all stages... found this request: ATLAS-65 - As a user, I'd like to create private Goals to ensure only specified users can view it 

[Nir Nikolaevsky]

Hi @Hailin_Zhang, this happens because of the way the default access settings are implemented. Goals and Projects have an automatic access toggle, when it's on (it is on by default) the default user groups for both Jira and Confluence are given access to Goals and Projects. Learn more here.

To decouple them you can toggle off the "Enable automatic access to Goals" toggle. You can find it under the the "Products" tab in Admin Hub. See attached screenshot.

On top of that I checked with the admin team and they told me that there are a couple of improvements they're planning for the experience

1. We're looking to improve the default access behaviour so it's not tied only to default groups and is easier to manage

2. Update the UI on the older user management page

We should have a public ticket for 1. improving the default access experience. I'll share it here when I get it. Hope this helps, let me know if you have any more questions! 

[Nir Nikolaevsky]

Hi @Greg D @Harrison Ponce @Stephen Neil @Stijn Veer, van der @Darrel Jackson @Dirk Lachowski @Filipe Vítor @Lai_ Ssu-Yuan _賴思元_ 

I'm now working on improving Goal and Project permissions, this includes better controls, more granular permissions, and private goals. At this stage I'm speaking with customers to better understand your needs and make sure we're building the right solution. 

If you have the time I'd love to jump on a 30 min call with you to talk through your challenges with the current system and needs for better Goals and Projects controls. 

You can book a Zoom call with me via this Calendly link: https://calendly.com/niratlassian/30min

Let me know if you can't find a time that works and I'll try to open up a few more slots. I'm very excited to be working on this, I know a bunch of you are looking forward to better perms so hope to chat to you soon!

[Stijn Veer, van der]

@Nir Nikolaevsky Thanks for the invite. Our time zones don't overlap. But I am happy to answer any questions via mail. 

[Nir Nikolaevsky]

Thanks @Stijn Veer, van der , can you please email me at nnikolaevsky@atlassian.com and I'll follow up from there :)  

[Sing Chen]

@Nir Nikolaevsky Would love to get involved in the permissions discovery conversations but being in the UK, our timezones don't overlap. Let me know how I can contribute. Thanks!

[Micah Schaafsma]

The critical path for most organizations is going to be able to control who can create goals and projects.  You want to publish the goals / project list broadly, but not give everyone the ability to create new ones.  

[Darrel Jackson]

The suggestion I've floated is that Atlassian introduce a goal type so we can differentiate between, say,  enterprise strategic goals and team goals. Currently the only way to do this is with labels.

Then Atlassian introduce a permissions scheme associated with the goal type where create/read/update/delete permissions are assigned to one or more of the following: Owner, User, Team (either Team assigned to the goal or a separate team) or Group.

In our organisation, for example, for our enterprise strategic goals we'd want to restrict "Create" and "Delete" to a separate strategy Team. But we'd want the Owner and the assigned Team(s) to be able to provide updates, create projects, link issues, add risks and decisions.

Team goals, by contrast can probably be created by anyone and updated/deleted by the Owner or the assigned Team(s).

[Anna Bergevin]

Super excited to see the progress on integrating these features into the main platform. I was a user of Atlas and looking forward to using this now that it's integrated. A few challenges:

- The name projects is SO confusing, given that term already has a meaning in Jira

- The fact that we can only have 1 associated Jira ticket is a problem. Projects is a tool we see being primarily useful for communicating with stakeholders. I'm on a large data platform team so we have a massive number of followers for our work across the business (some technical, some not). But the way our stakeholder customers think of a "project" and the way we might want to break down the associated engineering work are not always a clean 1:1 mapping. Sometime it is and that's great. But it's very limiting to not have the ability to associate multiple epics, lets say. 

- I wish we could ask multiple owners for updates. At least 2. Internally there are usually 2 leads on any given piece of work - a product lead and an engineering lead. Depending on the phase of the project one or both of those folks might have updates to share. If the product manager is the only "owner" then we have to go manually harvest update/context from our EM partners so we can give stakeholders the updates. This is particularly challenging on our platform team where one PM supports multiple squads - it's not the typical small product trio managing execution. Even if there weren't multiple owners maybe there would be a way to "@" mention the engineering leads and they get pinged on slack to also provide an update?