How to Bar the Door (or, How to keep everyone with your company email domain from joining your Asana Organization)

Most people set up their Asana implementation as an Organization (as opposed to a Workspace), and for good reason - there are many benefits to an Organization over a Workspace.

One property of an Organization is that anyone who has an email address based on the email domain of the Organization can join that Organization without asking for or obtaining any sort of approval.

In some cases this can be viewed as a good thing in terms of convenience and ease of onboarding. However, it’s important to realize that in a paid-subscription Organization, the person joining will use up a license slot and thus becomes a user who must be paid for. As a result, people administering an Organization may want to have control over who in their company (i.e. who have an email address using the company domain) can and who cannot join their Asana instance.

The traditional answer often seen is, “You can’t; anyone with the email domain can join!” However, there is a technique you can use, that @Julien_RENAUD and I recently learned about, so as to have control over new users.

Here’s how it works:

First, you set up the Asana Organization as a free Organization; i.e. it’s not on any paid Asana plan.

Then you set up a Division within that free Organization where the Division is at the paid subscription level you want (Premium, Business, or Enterprise). Note that you need to have Asana Sales set up a Division for you; it’s not something users can do on their own.

The key here is that by their nature, Divisions are closed to new users joining without being invited. People can only join a Team within a Division if they are specifically invited to join it; there is no automatic joining based on email domain.

Note that this doesn’t completely eliminate all possible issues; a Team member within the Division can still invite someone to the Team which might put the Division over their allocated number of licensed seats. But it’s a much more manageable situation than the alternative.

This technique isn’t something I’ve seen documented anywhere, but an Asana Sales rep should be able to set it up for you on request.

You can read about Divisions in the Asana Guide here, and you can learn more about the ins and outs of Divisions in this great forum post.

10 Likes

And the promotion of Divisions begins :slight_smile: glad we all learned how they work!

1 Like

Great post, our organization struggled with this for a long time and this looks like it would have been a good solution if we knew about it!

We recently set up SSO with Microsoft Azure, so now users have to be part of a specific distribution list in order to sign in to Asana. Unfortunately the error message someone sees when they aren’t part of that list can’t be customized, and people are sometimes confused how to gain access.

Very interesting, thanks for sharing. Some good learning there.

This prompted me to share a suggestion on that subject that I’ve been thinking about for a while, it would be good if we could have some ‘free licences as well as paid licences’ within an org.

Some users just need to be told when some tasks are done every now and then, and because they are in the same domain, they cannot be added as a follower to a specific task. It would be handy to have some ‘read only free licence’ within an org.

3 Likes

@Phil_Seeman, licensed seats taken up in a Division are merely a count of unique users across the Teams that are within a Division. The Administrator invites TEAMS, not users, to a Division. Users are invited/accepted as members of Teams (or Projects within a team) based on user permissions set at both levels.

Technically, a Division Admin can add a member to the Division but they are required to select a Team (and “starting project” if you like) to associate this user with. As shown below.

image

Sorry… don’t want to create any additional confusion or complicate matters, but it’s an important distinction to make. As the Admin of a Division, occasionally I have to address where users are invited to teams/projects and this happens to put us over our allocated number of licensed seats.

@Jonathan_Stern I made this suggestion some time ago but it hasn’t gotten much interest: Pricing Tier for Comment-only users

2 Likes

There is also the problem that you cannot always add new members to that team they need to go into. ie if you are not part of the team they need to be in, you cannot invite them into it.

So that must make it hard to manage that way.

Thanks, @LEGGO - a good and important point! I revised my post accordingly; can you check it out and make sure my revisions are accurate and reflect your point here?

I’m not sure what you’re meaning here; can you elaborate?

For sure @Phil_Seeman, I recognise that my comment was a bit hard to follow. I’ll illustrate with an example:
In our org, I am a member of some IT and management team but I am not a member of the sales team. When a new salesperson starts, as part of my user setup, I am unable to invite them to the sales team because I am not a member. I have to ask someone in that team to do that for me. (despite being the admin).

I hope this clarifies.

2 Likes

Looks great, @Phil_Seeman

1 Like

Ah, got it, very clear, @Jonathan_Stern.

I don’t know but suspect Asana would call that a feature, since one of the points of a Division is to insulate it. I would guess the majority use case is, like @LEGGO, where the Division admin is inside the Division. But when that Admin is outside the Division, I can see that scenario is not very cleanly supported.

I agree with you there. it makes sense from a security point of view. I sometimes wish as an admin i could see how many other teams are out there. but that’s another topic.

cheers.

2 Likes

Has anyone successfully received a refund after a licensed domain user mistakenly/without approval added a new user and increased the subscription level and cost?

We are a small nonprofit with limited tech funds, so I must now explain to my operations and finance leads why my team “allowed” an unauthorized increase in our Asana costs, so I am trying to rectify this if at all possible. So far, it looks like the SSO workaround and the team admin feature are only enterprise options and that divisions does not actually solve the issue either.

  1. A licensed user added a new user mistakenly and increased our cost and seat limit without approval
  2. We rectified our seat level to 15 seats within 24 hours by removing users to bring us back down to 15 seats used.
  3. We reached out to the user to remind them not to add any new users without contacting us for approval
  4. There is no way to prevent domain users from being added to our Asana license through Asana itself. When a licensed user attempts to add a new user to our account and it would increase our subscription level, they are given no warning nor is the request sent to an admin for approval. Should a domain user navigate independently to Asana and create their own account, they too are given no warning nor is the request sent to an admin for approval.
  5. We contacted Asana Support on April 1
  6. We sent 7 requests for a refund, inclusive of the initial support request logged
  7. Asana Support has continued to deny our refund because of the Annual Plan policy- despite the flaws outlined in #4 above- and stated that we must continue to pay the increased 20-seat fee through our annual subscription renewal date of December 2 2024 (even though we immediately went back to 15-seats)

fyi the way the support works, everytime you message them, it pushes your messages back at the bottom of the pile… Patience is key; support can take up to a week to get back to you sometimes :confused:

Thanks for the reply, Bastien. I actually didn’t have a challenge with support not responding in a timely manner- when I said “7 requests” I meant that as inclusive of the back and forth between me and support, not 7 requests without reply.

The issue is that I continued to receive the canned response that there is no way to prevent domain users from being added through Asana itself AND I cannot receive a refund for the 5 seats added without authorization. My case was escalated and I received that same response again.

I don’t want to replace the support, and I don’t work for Asana, but what they are saying is “true”: unless you use SAML with Enterprise you can’t prevent people from your own company to join, so they eventually charge for them if you don’t monitor and clean up. It does create disruption sometimes for sure. Not sure what else happened in your case :confused:

Thanks, yes, I understand that’s the policy. It just seems unfair that I have no way of preventing this and even though we remedied our numbers immediately, we’re stuck with the extra charges. Guess I’ll leave it at that as, yes, I know you don’t work for Asana - appreciate your replies.

That’s what’s very surprising because that should never happen unless this was exactly the day of the renewal date… I’d be happy to re-read the discussion you had with support to provide an additional point of view?

I recently switched from a Division plan back to an Organization plan. The main reason being that with an Org plan you have the ability to pause licenses. You do not have that option with a Division plan. Unfortunately switching back from the Division to an Org plan did reintroduce some users I had removed from the Division back into the plan. Pausing licenses gives me more flexibility to manage costs/licenses though. Every day, I check the activity though to make sure no one joined without me knowing. It’s a major hassle and my major pain point with Asana.

2 Likes