Discovery: What would you build with native "App Actors" / Scoped Bot Identities?

Hi everyone!

The Platform team is exploring initiatives around App Actors—giving agents, bots, and third-party apps their own unique, non-human identities within Asana.

Our main goals are to decouple integrations from human creator lifecycles (so things don’t break when a developer leaves the company) and, over time, build granular resource scopes directly into these App Actors so you can limit exactly what they can read, write, or create.

We know the community has come up with some incredibly creative workarounds using Personal Access Tokens (PATs), Service Accounts, or paying for “dummy” human user accounts to act as bots. We want to hear about your real-world friction points to make sure we design this solution to solve your actual day-to-day problems.

We’re looking for your use cases!

If you’ve run into limitations with PATs or Service Accounts, please reply and tell us about it. Specifically, we’d love to know:

  • The Orphaned Integration Problem: Have you ever had a critical business workflow or webhook silently crash because the employee who generated the PAT left the company or changed roles? How did you scramble to fix it?

  • The “Sacrificed Seat” Tax: Have you ever felt forced to purchase an extra Asana user license just to create a dummy account (like asana-bot@company.com) to run your internal scripts safely?

  • Security & Scoping Roadblocks: Has your IT or Security compliance team ever blocked an integration because a PAT or Service Account inherited “all-or-nothing” expansive permissions? What specific project-level or action-level limits do your security teams ask for?

  • Audit Trail Confusion: Do you have custom scripts where actions look like they were performed by a real human (the token owner) instead of the automation itself, causing confusion in the task story feed?

Whether you are building complex enterprise syncs, simple web-form intakes, or advanced AI agents, your feedback will directly shape how we build non-human identity into the Asana API.

Drop your stories, frustrations, and ideal workflows below! :backhand_index_pointing_down:

Hi @Nikko_Mendoza,

This exploration is incredibly exciting. I will probably think of more but right off the bat, here are two ways we would definitely use this functionality.

(1) When someone creates a Flowsana account, they have to authenticate to an Asana user, and all Flowsana automations they create run as if they are that authenticated user. That means (a) their Flowsana account has all of the access and permissions of that authenticated user (your Security & Scoping Roadblocks) and (b) all changes that Flowsana makes are attributed to that authenticated user (your Audit Trail Confusion) - our support tickets are littered with “why does it look like *I* changed all of those due dates, not Flowsana?” Having an App Actor would solve both of those for us.

(2) We recently introduced FlowAgents as a major new Flowsana feature. Currently there are two ways you can run a FlowAgent: (1) directly in the Flowsana builder (“run this FlowAgent now”) or (2) as a rule action. We wanted to add a third way: to be able to assign a task to a particular FlowAgent, and when that task becomes active (i.e. when its dependency is marked complete), that FlowAgent automatically runs. But implementing that functionality would mean a Flowsana customer would have to allocate a seat to that FlowAgent so that it could be assigned to the task (your “Sacrificed Seat” Tax), and we felt this would be too big of a hurdle for most customers so we didn’t implement this capability. An App Actor would resolve this issue and allow us to implement this third option.

I’ll let you know when I think of more use cases. :wink:

(Also, you know how to contact me so feel free to do so if you want to discuss any aspect of App Actors; I’m happy to contribute.)

Thanks for sharing more here! These are perfect use-cases for our agent. I’ll message you on the side if I have more questions!