You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
UPDATE: It’s a wrap for our AMA on Jira and Confluence Cloud Enterprise. Thanks to everyone for taking part and sharing your question. Be sure to watch the Enterprise space to get updates on new content, questions, and announcements.
I lead product development for the Jira and Confluence Cloud Enterprise plans that we released earlier this year. Cloud Enterprise is our most advanced offering for Jira Software, Jira Service Management and Confluence. We started with everything in our Premium plan and added enterprise-grade scaling, security and governance controls to support customers standardizing on our products in the cloud.
The most unique part of Cloud Enterprise is that you can set up as many instances of Jira or Confluence as you need, under a single, centralized, per-user subscription price. This enables organizations to set up instances of Jira or Confluence to enable team autonomy, delegate administration, segregate data for security or compliance, or fully partition unique apps and customizations. Cloud Enterprise also includes enterprise-grade security controls and centralized administration features such as SAML single sign-on (SSO), user provisioning and directory syncing, and our most comprehensive support offering.
On Thursday, August 26th 1:00 pm Pacific time, I will be hosting a real-time Ask Me Anything (AMA) to answer all your questions about Cloud Enterprise: how customers are scaling with multiple instances, how Atlassian is tackling security and compliance requirements, our plans for user management, data and analytics, end-user experience, and more.
Here's how it works:
Add your questions below any time before or during the AMA. Be sure to take a look at other community member’s questions and up-vote those that you find interesting.
At 1 pm PST on Thursday, August 26th you can expect to see answers from me and my team rolling in. Watch the page and be ready to add follow-up questions and discuss further with other Community members. We'll wrap the event at 2 pm PST, but will be sure to answer any questions we didn't get to.
An extension of James' question - with the recent acquisition of Chartio, are there plans to develop cross site analytics, for example, what is the most popular site, most popular project/space across all sites? Are users using premium features, e.g. space/page analytics, project archiving, etc? If so, where are they using them, e.g. on the HR instance, archiving is not well used, but it's heavily used by the engineering Jira.
Hey @JimmyVanAU thanks for joining!
Yes we are currently running an Early Access Program for our new Atlassian Analytics, which is designed to report and visualize on product data across multiple instances. You can learn more about the program and sign up here to test drive the features and share your ideas with the team.
Our Atlassian analytics investments are focused on improving the reporting and visualization of data that you generate in Jira and other products. We see it as a distinct use case from behavioral data for administrators about how end-users in their companies are using the product.
Hi @Dave Meyer,
Thanks for hosting this AMA. I have a question regarding the external collabortion in Confluence.
Will guest users count to the user tier or will there a special lower fee - for example if users only have the view permissions?
Can guest members be managed seperatly - for example attaching a time stamp to the account when the account will be revoked from the instance?
One question I do have in general: Will it be possible for Premium or Enterprise customers to set a custom domain?
Hi @Svenja - Great questions
Re: guest users - for our first version of external collaboration, it was important to us that these users were truly collaborators, and not just view-only readers, so they will use a paid license. We are considering an additional user role for view-only guests in the future.
Re: time stamp to an account - this is something we are prioritizing on our short-term roadmap but will not be available in our first iteration
Hi @Dave Meyer,
So cool you're doing this. Well, this question started as an inquietude about Data Residency in the Enterprise Cloud plan, and it escalated quickly; here it goes:
Thanks in advance for your time and for considering our questions. Regards!!
Hey @Huwen Arnone -DEISER- ,
Re: enabling data residency and offline time – It’s highly variable, in many cases it takes much less than 24 hours, in rare cases it can take more. We’re actively investing in both improving the overall speed as well as the accuracy of downtime estimates. That said, the unfortunate reality is that in some cases customers simply have very large (1+ TBs) of data stored outside of the target region, and transferring large volumes of data across an ocean simply takes time. We default to the 24 hour guidance because it's always better to take less downtime than expected than more.
Re: location criteria – I can’t speak to the specifics that led to us choose Frankfurt and Ireland, but generally speaking the factors that influence our selection are:
Availability of underlying AWS services that Atlassian uses in our technical stack (not all AWS services are available in all regions)
Impact to our business continuity strategy
Cost of those services
Legal and compliance implications
Ireland and Frankfurt are the most established and mature AWS regions in Europe, so at the time we established our presence there they were the logical choice.
@Nate Whitehead on your question, we’ve been transparent for several years that we will move customer data to reduce latency, improve per-tenant performance, and assure reliability and maintenance of our business continuity standards as our global infrastructure presence has matured. We plan to substantially accelerate our presence in additional regions and will continue this practice, obviously within the constraints of the data residency obligations that we now provide.
Simply put, we try to leverage our investments in a global infrastructure presence to provide a better product experience.
Again, thanks for taking the time to do this and going thoroughly with your answers @Dave Meyer
Looking forward to similar initiatives in the future 😎
Hi @Kishan Sharma ,
The setup steps for SAML SSO in Cloud Enterprise (and Atlassian Access specifically, which is included at no cost for Cloud Enterprise users) will be different from Data Center. You can review this support article to learn more, specifically the section “Set up SAML single sign-on for other identity providers”. We should be able to support any identity system that uses SAML.
We recently increased the per instance (site) user limit for Confluence to 20,000, regardless of plan. Here’s an article on this in case you missed it. That said, we strongly recommend our Enterprise plan as the most cost-effective option to meet the complex support, reliability, and security needs for deployments of 10,000+ users.
We are also actively working on expanding to higher user tiers in the future.
Hi Dave and thank you for doing this!
My question kind of builds on Svenja's - Would it be possible for Premium subscribers that have Jira only to get a free Confluence instance specifically (and limited if need be) for connection to JSM for the Knowledge Based.
I have not been able to get an enterprise subscription to Confluence for my company because we are dedicated to Microsoft 365 and the Sharepoint that comes with that. So I have no budget to add an additional license for Confluence just for JSM.
Hey @John Funk , very reasonable question. Unfortunately, while we’ve invested substantially in integrating Jira Service Management and Confluence for knowledge base use-cases, it still requires a separate Confluence subscription. However we do have a free Confluence plan that can be used by up to 10 agents to help you introduce Confluence to your organization and start showcasing the value.
Hi @Fabian Lim ,
See my answer here on multiple sandboxes. I would also note that our Enterprise plan customers can add additional instances with the same users for effectively no additional cost. https://community.atlassian.com/t5/Enterprise-questions/Re-Re-CLOSED-AMA-Jira-and-Confluence-Cloud-Enterpris/qaq-p/1912431/comment-id/78#M78
Even though the contest is closed and I am way late on this participation, I have the following question -
In the ENTERPRISE plan setup, what is the process of ensuring that all the customizations reside in one instance (site) be implemented across all other instances (sites)?
Best, Joseph Chung Yin
There's no special support for this right now in the Enterprise plan. Each instance can be administered and configured independently. We're working on improving project level export and import between cloud instances, which will make moving configurations easier. Targeted support for this scenario, like "configuration-only" exports and imports, or "templates" that can be used across instances, are definitely under consideration for our long-term roadmap.
@Pramodh M yes it's something we're planning to do in some form. It's not on our public roadmap because our immediate priority for sandboxes is to improve the speed, reliability, and coverage of the data copying functionality, but we discuss it regularly. We're tracking interest here: https://jira.atlassian.com/browse/CLOUD-11118
Hi @Dave Meyer ,
thanks for this opportunity.
Currently, the minimum number of licensees that we can buy for Jira Service Management Enterprise Edition is 400.
For Confluence Enterprise Edition is 800. When will the two offerings be aligned?
We would like to add Confluence Enterprise to our Jira Service Management subscription, but we should buy more licensees for Confluence (800) than for JSM, and it's hard to manage as happy Atlassian's customer.
The reason for the thresholds not being aligned is it’s not an apples to apples comparison. Pricing for Jira Service Management (JSM) is based on number of agents i.e. users who service customer (end-user) requests. On the other hand pricing for Confluence is based on end-users who collaborate across various confluence spaces and pages. There are fewer number of agents vs end-users in an organization and hence the minimum threshold for JSM Enterprise (201 - 300 agents) is lower than that for Confluence (801-1000 users). Correspondingly, the price per JSM agent is higher than that for Confluence user. So in fact the total cost for 400 JSM agents is comparable to that for 800 Confluence users. You can refer to our pricing pages for JSM and Confluence to get exact pricing for these tiers.
With that said, feel free to reach out to me directly at email@example.com so I can get more information about your scenario.
Thanks, @Dave Meyer . We are a system integrator and in our scenario we provide support services to our customers using JIRA as ticketing system, so we are all agents and our main use of Confluence would be as Knowledge base for our support services.
Anyway, I got your point, Thanks again!
This is great that you are hosting this sort of forum!
Our team recently took on administration of our Atlassian cloud products and it was a bit of the wild wild west before where every one was a site admin. You can only imagine how that turned out!
One of the cleanup tasks we took on was to streamline spaces (Confluence) and projects (Jira Software) so that teams can self-organize and manage access to their respective resources. It was previously decided to create groups for every project and space and permission users this way. Unfortunately, since only site admins can view members of these groups, the team members and even the space/project admins had no way of knowing who had access. We unraveled this and invited everyone individually except for the group (e.g., functional groups) that made sense.
Now that we did this, we were left with a lot of groups that are no longer being used for permissions. Ultimately, we'd like to delete these groups but am a bit wary since these groups can be used in a number of other components (listed below) which made it difficult for us to just go and delete the group without knowing the impact it would have.
The problem we faced was that there was no reporting on where these groups are used. For example, I couldn't lookup group "xyz" and know that it was being leveraged in a project role, permission scheme, 10 spaces and 5 projects.
I worked with your support engineers and indeed they confirmed that no such reporting existed so we as a team manually analyzed each and every one of the below to determine if a group marked for deletion was being used in any of the below.
Apologies for the essay. Do you know if any such reporting/analytics feature has been requested by other customers and if there were any plans to address this?
Hi @James Yoon ,
That’s a great question. As you confirmed, we currently don’t have a specific report for the use case you mentioned.
However, we plan to introduce a Data Lake, which allows cloud customers to access their Atlassian data by querying our optimized data lake with their own BI tools or extract and load that data into their own data warehouse for further blending and analysis. In short you will be able to build custom reports on Atlassian data to support your specific use case. Here’s the Early Access Program for Data lake in case you would like to sign up and get more details.
I would caveat this by saying that our general focus is on exposing Jira data, while this request is more about the configuration of Jira itself. It’s absolutely a valid use case, but not something on our roadmap right now. While it was possible to query the Jira database directly on-premises, we don’t have plans to support this in cloud. There’s some good discussion on this Community thread: List of all groups and where they are used
Hey @Bill Sheboy ,
We introduced the concept of an Atlassian organization, which is a “parent” for multiple Jira or Confluence instances. At the organization level, we aggregate key activities from individual instances (like user management events) into a single log, as well as changes that happen at the organization level itself (enabling SAML SSO, as an example). We consider this organization-level audit log our long term platform for logging improvements. It’s available with subscriptions to our Premium or Enterprise products, as well as all Atlassian Access subscribers.
Currently specific per-instance administration events for Jira and Confluence are in standalone audit logs on a per-instance basis (similar to Server or Data Center) but we intend to bring everything together at the organization level eventually.
Our admin insights feature works the same way: it aggregates based on the instances that are linked to the organization.
Hi @Dave Meyer ,
Thanks for briefing. Sounds interesting and promising.
I would like to know more on NFRs like performance, security and availability while these multiple instances are scaled up. Is there any major architectural change in contrast to earlier ?
My next question would be why people should opt for Premium Plan and how are they going to get the best service in long term?
Looking forward to hear more on the above.
Hey @Suvradip Paul ,
I assume "NFRs" are "non functional requirements" ? 😄
We target the same performance and availability baselines for all instances, regardless of plan, size, or customers. Sometimes meeting these baselines requires some variation in how we utilize our infrastructure, but that’s relatively rare. We undertake architecture changes continuously to improve all aspects of our products – for example, we’ve been able to achieve significant performance improvements moving from AWS RDS to Aurora, so we’ve been progressively rolling that out to customers.
There’s a detailed comparison of our plans for Jira here, but the short answer I would give you is that our Standard plan is for established teams that are focused on collaborating and organizing their work, Premium is targeted to rapidly scaling teams that need more functionality to support more use cases and users, and Enterprise is focused on global organizations that are already operating at large scale with mature Atlassian environments and stringent operating requirements.
Hi @Fabienne Gerhard! Thanks for joining.
Currently we support up to 20,000 users per instance for Jira Software and Confluence with plans to raise this limit to 35,000 by next year. We do have a fair use policy on the speic number of instances, but we expect to be able to support any number that can be reasonably planned and managed by a central admin team, since adding additional instances is not a fully self-serve process right now.
As a baseline, our largest Fortune 500 customers have anywhere from a handful to a few dozen production instances, depending on the right scenario for them.
Usually a "multi-instance strategy" for a company with one instance today means moving to 2, 3, or 5 instances tomorrow. Not several hundred 😊
Hi @Dave Meyer
It sounds like an interesting idea, so I take the opportunity to suggest
Confluence is a very powerful tool for teams / organizations for all the documentation, templates, etc.
On many occasions, clients opt for other tools, because they consider that Confluence has deficiencies, it has been proposed to reinforce this product with improvements in design, navigation, functionalities, etc., that make it stronger and nobody wants to change it for another tool
I love confluence
Hi @Vero Rivas , thanks for the feedback. We're working hard every day to make Confluence a better product. Personally, as someone who uses Confluence Cloud all day, every day I think we've made incredible progress on the design and performance of the product. Check out the roadmap! https://www.atlassian.com/roadmap/cloud?selectedProduct=confluence
Hi @Vero Rivas ,
We don't currently have a vehicle for collecting feedback on the roadmap directly. The public roadmap is the outcome of all the complex roadmap decisions we make across the numerous channels through which we listen to customer feedback, plus our company and product strategies, and all the other factors that drive any software company's product roadmap.
Hey @Brant Schroeder ! Thanks for joing.
On release tracks: since Marketplace apps from third-party developers run independently from Atlassian products, in separate infrastructure, we don’t have the technical capability to bundle apps. The ability to expose the release tracks configure to Marketplace apps so that they can align to it is on our roadmap.
On using sandbox with the release bundle, yes! We provide a special “preview” track for sandboxes that will release the bundle to your sandbox instance before production. https://support.atlassian.com/organization-administration/docs/manage-product-release-tracks/#Managereleasetracks-Configurereleasetracksforyoursandbox