nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Atlassian As A Service

Jeremiah_z8hmgk

I'm brewing an idea here but I wanted to reach out and see what other Atlassian users think.

Basically, I'm considering opening a new Atlassian account as an umbrella service account. I would then contract with other business (I have a few who need it) and completely silo out the users, projects, workflows, service desk, confluence spaces etc.. Each sub company under the umbrella would only have access to their relevant projects.

Would mixing the sub companies like this have any negative side effects I'm not taking into consideration?

Would it make more sense to help sub companies set up their own implementation?

I would like to hear your thoughts on if this is a good idea or bad idea.

Comments

Nic Brough -Adaptavist-

An instance of an Atlassian system holds a pile of shared objects that you cannot separate away by people.

Imagine the simple case where Alice, Bob and Charlie all have a separate Jira project, the permissions are set to only allow them into their project and they can't see the others. Next imagine you create three fields, again tied into their projects - say Shape-Alice, Shape-Bob, Shape-Charlie. You have some problems:

All three of those fields will be offered to them in searches and reports. Even if the fields are only populated in the separate projects, everyone will be able to see all of the fields on offer. If you share the field instead, so Shape appears in all three, it's less of a problem, but remember that everyone will be able to see all the options in the list (again, not the issues in other projects)

Alice, Bob and Charlie will be offered the ability to see and mention each other's accounts, with them appearing in other user-pickers in some cases.

Even if you turn off "browse users" for them, they can still stumble into them by accident, in search or mention - there was one system I worked with where there was a nic and a nicb and people often got the wrong one when they started trying to mention one of us. We re-enabled the user directory in the end.

Jeremiah_z8hmgk

Thank you for your reply. You raise some really good concerns. The fields I wasn't too worried about, but the accidental references might be the deal breaker here. I also wonder if this is against some sort of TOS. I'll have to take a close look. Thanks!

Nic Brough -Adaptavist-

Nah, it's not breaching any terms of service, you can invite whomever you'd like into your Jira/Confluence/Bitbucket etc, from any organisation you want, and then segregate them by project/space/etc as well.

Your main worry if you're going to do this is the "leak" between the various people and organisations, they can't be completely isolated from each other.

Trudy P Claspill

Another point to consider is that when the users go to the Project > View All Projects list they will see all the projects including the ones to which they don't have access.

You also need to consider the security needs of your clients. Are they operating in industries where co-mingling of data would make them out of compliance for data security standards for their industry?

And, what if your clients have clients of their own with whom they want to share the data? That adds another level of complexity to trying to silo the accessible data.

There is the concept of an Atlassian Organization that contains multiple Sites. A structure like that might work for siloing your clients if they each have a separate Site under your Organization. I have not actually worked with such an environment, so I'm not sure how much siloing it offers for users, specifically, nor have I looked at things like licensing and billing for such a set up.

https://support.atlassian.com/organization-administration/docs/what-is-an-atlassian-organization/

Jeremiah_z8hmgk

Great points here! Definitely glad I reached out! Thank you.

Jeremiah_z8hmgk

Oh I meant more along the lines of charging for my installation. Is it breaching if I monetize users on my side.

Nic Brough -Adaptavist-

Um, actually, only admins get to see the full list of projects. If a non-admin user doesn't have "browse project" for a project, then it won't be shown to them in the list of all projects, Jira hides it completely.

But the security needs there are definitely things to think about.

Trudy P Claspill

Ah, I am a Jira Admin, but not a Site Admin (anymore), so I can't always tell what non-admins can see. I thought from discussions in the Questions section that folks were indicating non-admins could see all the Projects in the Projects list, but if they try to drill into the project then they get permissions errors.

Thanks @Nic Brough -Adaptavist-

Matthew Stublefield

I believe this is a violation of the TOS @Jeremiah . See 3.3.b of https://www.atlassian.com/legal/cloud-terms-of-service:

3.3. Restrictions. Except as otherwise expressly permitted in these Terms, you will not: (a) reproduce, modify, adapt or create derivative works of the Cloud Products; (b) rent, lease, distribute, sell, sublicense, transfer or provide access to the Cloud Products to a third party...

There's a similar clause in the on-prem TOS.

Jeremiah_z8hmgk

Good find! I'm wondering if I couldn't do something like @Nic Brough -Adaptavist- mentioned. Where, I'm not charging the client specifically for seats, but rather my administrative services and they just happen to be apart of my over-arching organization?

Jeremiah_z8hmgk

Well, wait a second now. Doesn't this bit in the 3.3 Restrictions section bascially say we can't offer Atlassian products and services to a 3rd party?

... (c) use the Cloud Products for the benefit of any third party; (d) incorporate any Cloud Products into a product or service you provide to a third party...

Do you think I would be able to sell myself and say "hey, I can install, configure and help you manage an Atlassian installation." Or, does that break the terms as well?

It would just be easier if I could just say "hey, I have a thing. Do you want to be apart of it for $x/mo".

Matthew Stublefield

I actually spent a lot of time chasing this down with Atlassian's legal team a few years ago. The key is that the license has to belong to the organization using it.

So let's say I want to run a company helping people with their Atlassian instances. I can totally do that, but the license has to be in their name, not mine.

I can't spin up 10 instances, give access to people in 10 different companies, and help them with it.

Instead, I can help 10 different companies spin up instances, which are licensed to those 10 different companies, and then I can assist them.

...I'm not charging the client specifically for seats, but rather my administrative services and they just happen to be apart of my over-arching organization?

You can charge for the services, but it may be in violation of the TOS for the customers to be part of your over-arching organization because those customers are actually part of a different organization.

There are businesses that use internal chargebacks where IT will "bill" a department for running an instance or providing support. That's allowed because the department isn't a 3rd party, they're part of the same organization. That isn't what you're proposing here, though, which is why it runs afoul of the TOS.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

jira

jira-software