Well, @Phil_Seeman you did mention that adding a user incurs another seat, but I’d like to shed some light on how specifically we do this internally and how this could be done in a quick-and-dirty way to not cost a seat.
As long as the bot doesn’t depend on being a “full member” (some API activities do, like defining new custom fields or modifying their settings) we spin up a new Asana org and create a user in there, then invite them in as a guest in our org (the same way you send a team invite to a teammate). This user is free as long as they don’t have the same email domain as the host org - that is, these users in Asana don’t have an
@asana.com email address so they don’t count to our billable seat count. Even more specifically, there are a list of in an organization’s Admin Console => Settings => Associated Email Domains and any email not in this list is not treated as a full, billable member of their domain.
The way I would go about this if I were in another organization is, with IT approval, set up a subdomain (which should be pretty simple) and an email client that can handle email there (more tricky, but doable) and creating accounts for bots in there. Then they will have their own presence in Asana but not cost a seat.
Now, the reasons we don’t document this are:
- This is a business logic that’s not controlled by our platform teams so other internal Asana teams could change this behavior,
- The visibility of Asana is different for this bot - you have to, for instance, invite them into each team vampire-style before they can see it or the projects in it. (or add them individually to projects but not the team). In Asana full members can see all teams that aren’t hidden. This, too, is changeable behavior that other teams control. On the other hand, it actually provides something like a layer of access control if you understand this different setup and so is arguably better!
If this is acceptable, then it’s possible to have something quite close to bots already!