By way of illustrating my request, here’s a query I received from a Flowsana user:
Our Flowsana account is in my name and we are using it within our Organisation. The problem is, no matter who amends dates, etc in Asana, it reflects my name against though changes. I’m getting a load of enquiries as to why I’ve made changes in Asana, when in fact it could be any one on the team making the change.
My question/request is, have you guys considered, or would you consider, providing an option for an API key to have an associated “display name”, and when that API key makes changes in Asana, those changes are shown as being from that display name instead of made by the user whose Asana account was authenticated to?
(I know one could use a Service Account for this, or could create a special Asana user, but the former option requires an Enterprise account and the latter requires paying for an additional user. I’m asking more for an API-specific global option.)
Thanks for providing the example to clarify your feedback. I agree that this would be helpful. I will discuss the feasibility of implementing it with the API team.
As a workaround, I suggest that users create an Asana account specifically for these types of apps. They can name the Asana account something like “Flowsana bot” and then have this user generate the PAT. Then the stories will show all of the actions being taken by the app and not a human user that manages Flowsana.
If you need access control for the bot, you can use an Asana guest account to generate the PAT. Then this bot user will only have access to the projects they are invited to.
We hope to have a better native bot experience in the future, but this is the workaround we use internally.
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!
Thanks, @Matt_Bramlage! I think for something like Flowsana, it would be too complex to offer as a general solution, so I’d still advocate for my custom-display-name request; but it’s great to have this detailed info should any of my customers want to specifically implement something like this.
I would love to hear if any progress was made on this original request for some alternative method of listing a custom username with a PAT that doesn’t involve a Guest account, or if a Guest is still the recommended practice.
