Notifications
Clear all
Topic starter
12/06/2026 9:00 pm
TL;DR: Asana integration workflows can automate license tracking, provisioning, deprovisioning, and account creation, but they also widen the identity governance surface around access scopes, admin authorisation, and offboarding discipline, according to Zluri. The real issue is not productivity, but whether lifecycle controls keep pace with the identities being delegated into workflow tools.
NHIMG editorial — based on content published by Zluri: Automation: How to get more out of Asana via Integration with Zluri
Questions worth separating out
Q: How should security teams govern app integrations that can create and remove user access?
A: Treat the integration as part of the identity lifecycle, not as a standalone productivity add-on.
Q: Why do workflow integrations complicate access reviews?
A: Because they can hide the difference between who uses a tool and who is still entitled to use it.
Q: What breaks when deprovisioning is handled only in one system?
A: The user may disappear from one application while remaining effectively active through linked accounts, scopes, or delegated permissions.
Practitioner guidance
- Review integration scopes before authorising access Limit the Asana scopes granted to the connector to the smallest set needed for discovery, workflow actions, and licence administration.
- Bind provisioning to authoritative lifecycle events Trigger account creation and removal from a reliable joiner-mover-leaver source rather than manual tickets or ad hoc approvals.
- Separate usage reviews from access certification Use licence utilisation data to identify dormant accounts and overspend, then run a separate entitlement review to confirm whether each account still needs access to projects, tasks, and administrative functions.
What's in the full article
Zluri's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step Asana integration setup flow and scope selection sequence
- Account authorisation and instance-saving process for administrators
- Example use cases for licence tracking, provisioning, and deprovisioning
- The vendor's walkthrough of how multiple integration instances can be configured
👉 Read Zluri's Asana integration guide for workflow and lifecycle details →
Asana integration governance in IAM teams: what changes now?
Explore further
12/06/2026 10:47 pm
Asana integrations are an identity governance problem, not just a productivity feature. The article frames the connection as workflow efficiency, but the real control surface is delegated access into tasks, projects, and administrative settings. Once a connector can create accounts, assign access, and monitor usage, it becomes part of the identity plane. Practitioners should treat every such integration as an access pathway that needs governance, ownership, and review.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who should own the governance of business app integrations?
A: One team should own scope approval, another should own usage monitoring, and a named identity owner should own revocation and lifecycle control. Without explicit ownership, integrations spread across departments and no one can prove who approved access, who reviewed it, or who removed it.
👉 Read our full editorial: Asana integration governance: what Zluri changes for IAM teams
