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.

9 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.

2 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