Hi,
I’ve just started using Team Knowledge. (I still don’t understand how it works)
As you can see in the attached image, words in the comments field are underlined, but it doesn’t seem to work for words in the description field.
1 Like
That would be awesome indeed! cc @Arthur_BEGOU
1 Like
Yes, @lpb noted this shortcoming:
Larry, I think you’ll want to vote here!
2 Likes
I agree and voted, too!
2 Likes
I really think this would be the single most impactful feature to spur widespread adoption in my department.
From day 1, we wish new hires good luck in learning all our jargon. We have people who’ve been here 10 years and still don’t know it, in part because because it is changing constantly. The ability to reference jargon definitions seamlessly in-context, and manage it centrally (search and/or sorting of the knowledge base would also help greatly, but is less essential) would be a game-changer for so many of my teammates.
Currently, this feature is functionally comparable to a dictionary since the contextual hovercards don’t appear in the description field (or in task titles or Notes views!) as you would expect.
Please implement this. I don’t know what technical limitation stopped this from being included in the initial release, but from my point of view it really seems like it would be a massive bang-for-your-buck win for Asana.
1 Like
Asana always do baby steps, but they are listening!
1 Like
The new team knowledge field could be much more useful it activated on terms in the description of tasks, the overview tab, and the note tab. If team knowledge functioned in these places, it would be help significantly with onboarding.
I’ve merged your post into an existing topic where you can click the title to scroll to the top and vote by clicking the Vote button.
Thanks,
Larry
Note: Not a solution but marked as such to elevate a key reply
Wanted to note that after some research, this feature is actually implemented, but in a way that is definitely not useful to superusers posting here, but can be for other users in certain contexts.
If you do not have edit access to a field, the feature functions. So you have to implement your projects, workflows, and access controls in a way that limits user functionality to have access to this specific feature. Some examples of where you can see this:
- Project Overviews where the user is not a project admin
- Task descriptions in reference projects, so long as users do not have edit access. If a project admin wants to benefit, they will need to hand control over to another user (who would then not benefit) or to some sort of service account
- Task descriptions in working projects, so long as access controls are strict and the user is not personally working on the task (lol)
- Note tabs in any project where the user does not have edit access
Realistically, this means this feature is broadly functional for reference projects, for users who do not need to interact with tasks and projects, and for project overviews. It is explicitly unfriendly to project admins.
For a tad more technical detail, it seems this limitation is specifically related to the fields with hover-over edit functionality, which is missing from comments and why we are able to see it function there. I assume that is the technical hurdle where feature development thought best to stop for this initial implementation.
Despite being more functional that I/we thought, the feature is still limited enough that I believe it highly valuable to expand on.