Add User with Same Domain as Guest

Hi @Sara - Is this specific to an Organization plan or does this also apply to a Division plan as well?

We’re in the process of setting up a Division plan and we’re hoping we can have internal company “Task Collaborators” that have our company domain email but don’t count as a licensed user. Is this possible on a Division plan?

Welcome, @Guy_Anela,

I believe that’s correct: In a Division, you can add task collaborators (or task assignees) and not count in your Division seats. They will count only if you add them as Project Members or Team Members in your Division.

Be aware that, because they can’t see the project or team, these tasks will be free-floating for these folks–not really appearing tethered to a project as they will to those in the Division.

Larry

2 Likes

Thanks @lpb!

1 Like

Need to have the ability for individuals currently within organisation (i.e. have organisation email addresses) but don’t need a full license, just need to view read only projects and be assigned tasks.

Guests accounts as such but for people within organisation. Or at a minimum reduced licenses

2 Likes

Truly, I believe this is a most fitting proposal.

Welcome to the Asana Community Forum @Jennifer_McCallum!

I have found an existing feedback request thread and merged your post. Votes were transferred too :slight_smile:

Hi, @Jennifer_McCallum

“at a minimum reduced licenses”
Is there anything that resembles this?

This is critical for our use as well - adding some additional context from a very large organization:

We have a very large organization and not every team uses the same tools as we have different needs. Our org has some kind of enterprise level account and for a user to gain access, there is a request process that includes a yearly recurring internal cost center to cost center “payment” required per user/member/paid seat defined by our technology dept to offset the cost of the total plan. Meaning each user needs funds available in THEIR cost center and approval to use it in order to gain access. Our department leads projects that includes several other individuals in many other cost centers, and who we are working with from those departments at a given time can change with each project or even throughout a project. This means we have several people in our organization (same domain) that may only ever be responsible for a few tasks or approvals, and then never again. It is unreasonable to ask them to purchase a (not cheap) recurring license cost from their cost center just so we can assign them a few tasks for one project. There are a few key people we’d suggest to purchase a full license for a better experience, but many others who should not have to. We don’t want internal funding situations (which can be tight and heavily scrutinized) to impact adoption of the tool we want them to use. We also have security restrictions and cannot use a personal/alternate email address with a different domain.

I’m trying to convince our dept head that Asana is the tool we should be using for project management (and not Jira which our development teams use which is gaining more traction throughout our company at the moment), but this is the biggest roadblock I’m seeing to our adoption. If we can’t make it easy to use for the hundreds of people outside our department who may need only a few tasks assigned to them ever without blowing up our cost centers, I don’t know how we’ll realistically implement this. It seems like such an easy thing for Asana to do and such a specific restriction that doesn’t allow for organizational flexibility. Our org is already paying for an enterprise level account, but if we (users on the ground) can’t get it to “stick”, our technology dept could decide at any moment that they’re getting rid of Asana and shifting everyone to another tool like Jira. Really hoping for a solution to this as we are in desperate need of a functional and robust project management tool which I was hoping Asana could fulfill.

Thanks

1 Like

Hi @staciiicates - welcome to the forum! I don’t think this 100% solves your problem, so please do make sure you vote for this topic if you haven’t already, but have you considered moving to division plan(s)?

From my (somewhat limited) knowledge of the pros/cons:
Pros

  • You get finer control over who consumes what kind of license while still allowing everyone to be in the same organizational domain (by email address)
  • You get different bills (? I think) for each division, solving your cost center chargeback issue

Cons

  • You lose access to some admin features (app enablement, service accounts, etc.) or need to go through Asana support to utilize them
  • Maintenance for SCIM is going to be more complicated
2 Likes

Let me give you just a little bit of advice.
Jira and Asana have very different purposes and usage, so I think it’s better to use both.
I think Jira is especially suitable for development.
Regarding Asana, in addition to the members who use it all the time, you have several licenses for arbitrary users, and those licenses are for visitors.
I think it would be a good idea to allocate the visitor page to a temporary member who will be involved from time to time.

1 Like

@Ka_Nishiyama thank you, I didn’t know to ask about different license types. Would this be something managed by our company, or that we’d have to work with Asana support to allow a subset of in-domain visitor licenses for temporary use?

From your comment I’m not yet clear on if what your suggesting is either

  • a paid seat / full member that we as a company would just manage differently internally with how we activate/deactivate and manage cost center payments for
    or
  • a setting or user type of some kind that allows in-domain (same email address) visitors
1 Like

Hi, @staciiicates
Was the explanation vague?
There is no separate license for visitors.
The license agreement with Asana is a quantity contract, and is not a fixed individual contract.
Within the number of license contracts, users are invited by email address at the time of actual use.
For members who no longer use the service, the number of licenses used will be reduced by deleting the registration.
The proposal is to sign a contract with the total number of licenses, which is the number of members in the department you are currently using plus the reserve number (this is expressed as visitor use).
For example, if you contract for 50 licenses and the number of actual users is 40, 10 licenses will be reserved.

Hi @staciiicates ,

As an enterprise customer, I presume you have an account exec and/or CSM that your org liaises with? I do think it might be worthwhile for you to reach out to them with your situation and ask for guidance on licensing options. Although you cannot (currently, as is referenced in this thread) have accounts in your domain serve as only guests in your organization, I think you could perhaps have an enterprise division where the bulk of your work takes place and also a free (or other paid tier[s]) division(s) to which all your non-regular users are assigned. I believe they can be added to specific work within the enterprise division while still consuming the lower license of their division.

The tradeoff is that admin is much more complicated and limited, so it may not be ideal for a large-scale org with extremely rigid infosec policies. Again, I’m not particularly well-versed in this, so hopefully another forum member and/or your Asana contact(s) can provide definitive info.

2 Likes

In conclusion, there is no such option. Even if you set up a division, you cannot make anyone in your domain a guest for your team.

2 Likes

As an Asana Admin, I get lots of people wanting to use Asana, however when they discover that you can’t make someone a guest with same domain, they are put off by the product as they can’t justify the cost for giving a user a paid licence, especially if they just need to keep tabs on things. I.e. not not add, delete or interactive with anything just maybe comment or just view.

We currently are on the Enterprise package and there is just no justification at all to give someone in our organisation a ‘viewer only or commentator only permission’ because we will have to fork out for a full paid licence to access this, and lots of features they will never use.

The best user case is if a Director or Heads of function wants to have access to Asana and only need to see progress of a project and maybe add comments. Non paid guests are able to do this, so why are people with same user domain not allowed?

The read only view link solution doesn’t offer enough flexible to use as alternative because it doesn’t allow for custom fields to be surfaced, so the choice at moment is very black & white, we have to either fork for full licence or create reports manually off Asana to keep Directors, Head of function etc informed.

Suggestion to Asana:

Look at permission structure at user level not project. For example, create a viewer only permission and/or Commentator only permission against the user profile (controlled by admin) not the project itself that mimics the permissions of guest. This could them treat the organisation users like a guest and give them read only access for example to projects, dashboards etc across the system, without taking up a licence.

@Ben_Turewicz - as an Enterprise customer, I’d reach out to your CSM/AE and enquire about licensing/plan structure (org/divisional). Additionally, for your specific use case, you might ask them about view-only licenses if you use SCIM (full disclosure: I have not tried those at all and apparently they are in a limited release, so not 100% sure that’s a viable option).

@Stephen_Li thanks, we don’t use SCIM unfortunately but will speak to my account manager. Been trying to understand bit more on this Viewer permission so thanks for link. My suggestion would be a simple approach that appears in the ‘membership’ profile management area for users. Asana could add a 4th level called ‘Viewer’ or ‘Guest member’ that could be set up and therefore treat them like a guest despite having same domain as organisation. We also have Paid Division complexities but wont go into that :slight_smile: (see example image below)