I haven’t explicitly seen specifics around how we could get to a “generic” work item type in ClickUp, as opposed to everything being called a “Task”. So I wanted to propose some suggestions:
I think there are a few simple ways that tasks could be presented that would give us most of what we are looking for, and really make ClickUp a massively flexible tool:
  • Allow tasks to be called what they are “tagged.” I have been using Tags this way for a while in my ClickUp. Similar to “Issue Types” in Jira. So I have tasks that are tagged “bugs,” or “meetings.”
If we had some preferences to require a tag upon task creation, then you could practically accomplish this.
In the case of actual tasks, you could simply use the tag “task.” The existing graphic appearance of Tags is outstanding so UI wise, there would be no change needed here.
  • Remove some attributes that are typical to Tasks:
  1. Due Dates
  2. Time Tracking
With this, you get a great capability to more accurately represent a host of stuff a lot of us are tracking in ClickUp.
These things don’t need due dates, for example:
  • Customers
  • Assets (laptops in use by the team, phones, etc.)
  • HR Candidates
  • Software features - often persist and don’t really have a “due date” - the task to build them does.
With this structure and the evolution of Relations, you could build almost limitless tracking of all sorts of work in ClickUp:
CRM: You use your Client “item” only for your client, and then you relate tasks to represent activities (“send the offer”). With Automations, you could automatically move the status of the Client depending on how the related items are tracking.
Candidate Recruiting: You can apply to each Candidate the work around he/she, like “conduct interview” and track the time that takes. In reality if a Candidate is a task and moves in a board based on the process in recruiting, you aren’t really tracking “work” around that candidate, just the status.
Idea Management. This way you could log ideas as items, such as in a “bank” like in the GIST Planning methodology. You could then attach Intercom feedback in a related area to each of these ideas and get a great view into specific conversations that were discussions various suggestions the team is working on.
Software development: In reality, the classic Feature - > User Story - > Task structures is not really something that is accurately represented by Task & Subtasks. User Stories aren’t really “work” to get done, they are persistent areas of a software platform, and they have tasks that are done to build them. This is even more true of the Feature - > User Story relationship.
I think this would be a great help to the multiple instances I read on the community here where SubTasks are used as data types, entities, etc. and are not really “sub” work of the parent. Wrike and Asana force this structure, too, but its unnatural.
With 1) a little more work on Relations, and 2) the ability to have what’s now a “task” in ClickUp with attributes of an “item,” you can replicate very accurately the functionality of a good CRM, inventory tracker, ATS, Product Planning app, the list goes on!
I wanted to reference a few other discussions on the subject:
Great commentary from @zeb-1 here
And this one:
There is also this new post talking about the wave of nocode Apps, and with some of the flexibility in ClickUp now with relations coming along, Goals as an entity where tasks can live in many, ClickUp is also right in this category.
Thanks guys and eager to see how this evolves!