Attributes Best Practices

I’m working on outlining a proposal to move our org to Height. The benefits over our current solution for end-users and daily work in general are many, and the Webhooks will provide all of the data we could want for… well, anything.

I have been wracking my brain on the best approach to Attributes. Specifically: what’s the case for utilizing specific Custom Attributes (e.g. client, department, etc.) over a single more generic “tags” attribute?

More broadly: what’s the case for using a specific Custom Attribute over a list? The attribute will allow segmenting within lists, but in the context of Smart Lists you can segment by list names.

I think that’s one of the areas I get tripped up most (depending on the context, the name of a list can be thought of as an attribute).

My best answer to this question right now is that Custom Attributes should be defined for critical areas of separation. In our context (advertising agency), that’s going to be at least Client and Department. …but I’m not confident that this is actually correct/best!

1 Like

Hey, Michael!

Your line of thinking is actually what we typically advise: Custom attributes are best for granular specificity, e.g. Client, Department, etc. However, to your point, lists can be treated as “tags,” too!

For attribute v. list, we typically specifically advise lists over attributes for managing sprints in Height. Setting up sprints at an attribute level simplifies (manual) rollovers, and just in general, lists are best used for larger projects than span weeks/months instead of iterative (bi)weekly tasks.

The main takeaway is that leveraging attributes helps to streamline the overall organization of a workspace. Instead of having dozens upon dozens of smaller lists that contain a handful of tasks, you can keep the workspace tidy by relying on attributes (that can exist “in the background” and be hidden/shown in lists when needed.)

Our intended design for the Custom attribute feature is exactly as you mentioned: for users to create workflow based fields for defined specificity. Tag is for sure more generic, while an attribute like Client or Department drills down on the specific value.

Let me know if this helps!