Manage Jira & Confluence sites quicker and easier

[#1]

Hello to all admins of Confluence Cloud and the Jira Cloud family of products. Thank you for your ongoing feedback on how we can make collaborating and sharing your projects and content in our products even easier for you. We have listened and are excited to introduce great new ways to help get the teams in your organization collaborating quicker in Confluence and all of the Jira products.

Move work forward and get teams collaborating quicker

Users now have a whole new way to request access to the entire Jira suite and Confluence. No more searching and trying to identify the site admin to ask if they can add someone as a user. No more email chains and chats or random desk drop-bys. Users can now request access to Confluence or Jira right from the product.

Say Alana shares a Confluence page with her teammate, Will. He opens up the Confluence page and sees a few Jira issues linked, but can’t view the details since he doesn’t have access to Confluence. Will can click on the Jira link and request access directly from the product. As the site admin, you will receive the request in their inbox and the Access requests page in the site administration portal.

In addition to managing all of the global permissions, including user requests and provisioning, site admins had to deal with incoming access requests via a variety of channels and no easy way to manage them. Now, you can enjoy a streamlined approach with a daily email for a batch of all request users, while users are able to gain access to the tools they needs to be more productive much quicker. Admins still have the opportunity to either approve or block access. When the decision is made, the user will get notified via email to help close the loop. The flows below shows how quick and painless the process is first for the user and then for the admin.

 

 

Domain Enabled Sign Ups: Fuel collaboration with frictionless sign ups

Don’t want to make your team wait for access, holding them back from working together? You can set up simple access control rules for future requests with domain enabled signups. When you enable this feature, everyone on the same email domain (@acme.com or @[deleted].com) can sign up on their own, making it frictionless to join. This means less emails and approval workflows for admins and more power for all users to get collaborating on projects quicker. Take a look at how easy it is to enable domain enabled signups on your Atlassian cloud site below.

Coming soon: Build a trusted network of site managers

Managing an entire site comes with a lot of responsibilities and you don’t always know the full context behind the needs of each user. Wouldn’t it be great to have a group of trusted users to help? In the next few months, site admins will be able to delegate some of their responsibilities to a network of trusted users. This is a new permission level for users, giving them more capabilities than a regular user, but without the full extent of a site admin role. Without needing to go through site admins, trusted users can add new users and install new products on their site and configure them. However, only site admins have the power to choose who can become a trusted user and can change these permissions at any time. 

We’d love to hear what you think. Please share your feedback in the comments below. There’s no better time than now to get all your teammates collaborating and moving work forward in one place. Go ahead, invite your team to collaborate with you on a Jira project or Confluence page.

[Stacy O'Dell]

We have a separate process for requesting access to both Jira and Confluence in our organization.  It would be amazing if we could specify the URL to be redirected to if a user requests either Jira or Confluence access (one URL per application, if possible) -- that way when they click on the "request access" button it redirects them to our system instead of sending an email.

[Marek Kiwilszo]

Good to hear. Would be nice if you could resolve bugs in cookies. Old cookies make many users unable to logon. Clearing browser cache fixes the issue but we do use wiki also in non IT/dev departments where senior engineers hate to troubleshoot your software. They expect it to work. Would also be nice if we could use AD to login them automatically.

[Marine Lacourie]

Is it rolled out already? I can't see the request for access functionality.

Thanks!

[Tihomir Voynski]

Hi team,

Good to hear such of improvements.

Those updates are also not visible in our Org Site admin panel.

We are using Cloud family products

Do you have any release dates?

Thanks,

[Jared Albers]

I can see the 'Access Requests' page on my domain, however below is what our Confluence-Only users are seeing when attempting to view JIRA tickets on a Confluence page. They aren't seeing the table of JIRA issues. So how is this meant to work exactly?

[Trevor Hutt]

We have our entire business on Jira.  Everyone from Finance through Projects to Product Services and Customer Education uses Jira to track work.  As the Jira admin I would love to delegate Project creation, board setup and adding users to our Jira without having to expose the full capability of the Admin role.  Looking forward to seeing the new feature.

[Maija Ļaksa]

New interface for user management has few worse features than it was before:

1) Access details sections takes a lot of space - old view was more compact

2) Only 5 assigned groups visible at a time - very inconvenient to page through all assigned groups

3) Not able to open navigation in a new tab - Show details, Invite users

Disappointed :(

[Michael Mothersill]

Trusted user sounds great.  But I would want to be able to grant such a user very specific permissions such as ability to add/inactivate/ users, add apps/plugins, etc. all separately.   There should be restrictions too such that a trusted user can not change/deactivate a site admin.   I do not want to have a trusted user  both handling new user requests and being able to add apps.   Adding apps/plug-ins is a big deal and can cause many issues (we always try out new apps in a dev/trial instance first) and would not want a trusted user to do that.

[Richard Lawn]

Looks like a good feature, but what versions of JIRA and Confluence is it in/will be in, please ?

[Michael Mothersill]

Richard - I don't know, I was just commenting about the update on this page for suggestions/get clarifications of this upcoming feature (see Coming soon: Build a trusted network of site managers above).

[Kieren]

@Marine Lacourie, @Tihomir Voynski, @Richard Lawn - Request Access is now available to all cloud sites using Jira or Confluence.

@Trevor Hutt, @Michael Mothersill - In the future, we'd like to allow admins to customise these roles (like Trusted User) and create their own combination of roles and permissions.

[Kieren]

@Jared Albers - This is a known problem for us; we can't show a list of Jira issues to the Confluence user using that macro, because they dont have access to Jira. We're working on some of these edge cases to improve the Request Access function :)

[LQ]

@Kieren I'd like to add on to @Michael Mothersill's concern - Trusted users today are granted equivalent product admin permissions, and to ALL products on a site. They are also counting towards all product licenses individually. This can be a problem if a Trusted user is not needed for a particular product.

My use case needs a way for a trusted set of users to only be able to add/remove users from a given set of product groups, and not count against a product license altogether if product access is not needed.

This is especially beneficial when SCIM is not yet available or ready to use.