Whenever I create a new task of this type, it will come along with all your custom fields - this is the solution that best suits us.

Task Types need certain questions/data points based on the task, location like we have is true to "location". One Department needs these set of data points compared to another department needing theirs. Ours would probably be 80% Task Type and 20% Location. But need both to make my reporting needs for my location.

Today's functionality causes all the fields to meld into the task when a task is shared with other locations. Our project task types then have all the enhancement task type fields and our data is skewed because of it. I have to go in constantly to remove fields in a location that got moved because someone added a task to that location and "moved" the fields. I would love for that to be locked to "admins".

I would use both task type and location based fields. I also think custom field sharing should be an option (eg, "Client" can be relevant in different types of tasks and locations).

If we were to start over, I'd probably be a 50-50 split between types and locations. Custom fields by task types would definitely be helpful, but removing custom fields by location would mess up a lot of our lists. For example, I use dropdown custom fields quite a bit to organize and group lists. We used to use Asana, so when we migrated most of the "sections" transferred over as individual lists. I've consolidated a lot of those lists into 1 list with custom fields to group the tasks by.

Our product team heavily uses task types, so that's where it's most helpful. However, other departments like marketing and operations don't use them as much, and that's where location-based custom fields are really handy.

I'd love to see custom fields by task type, but we definitely still need them by location as well.

hello Ivan Villa, if we were to start over I would say that 99% (if not 100%) of our custom fields would be based on task type.

We migrated from JIRA (and this is how JIRA works), so there may be some bias, but here's how our process works conceptually.

We have Spaces per team and under that lists represents contracts or major projects (some internal, some client facing).

A project is composed of a number of different task types which are executed by different teams, for example: stories, projects, bugs, content items, design items, contracts, etc.

We would like to see each of these tasks types be defined somewhere globally, and then they could be used in any space/folder/list in the same way.

As a specific example, a "bug" is a "bug" anywhere without our company. There could be bugs created by our internal product team, or clients projects, or support tickets. A bug needs information like:

Once these custom fields are defined, if anyone creates a "bug" somewhere, all of those fields should be available.

The same holds true for any other task type.

With this proposed functionality, what we would do is:

In this way, the PM has visibility of the bug, and it is correctly associated with the project. While the Developer ALSO has visibility to the bug in their own space, along with bugs from any other client projects (or other sources).

If you want more information, please feel free to reach out.

1) When you open a task would you like to see both the location based and task type based custom fields? or would you like only task type custom fields to show when you open a task with a custom task type?

>> Answer: A combination of location and task type would be great. See next answer for example:

2) If you have specific examples where you would combine task type and location-based custom fields and how you plan to use them, please share 😊

>> Answer: Some 'Tasks' are not really tasks, but rather an item in a list. For example - I have a task type 'Content' which includes the content type (Blog, Article, etc), Source, date, and other metadata about the content.

This task type could be a subtask of a bigger task, providing information about the task.

Another task type could be 'Resource', which could be a link to a website, a video, or an image.

Not all content and resources (in the example above) are the same. In one workspace or folder I may have different requirements for metadata about the resources than another.

If I need the same customer fields for all tasks of a particular type, I could create the customer field attached to the type, and the root of my space (much like the way it is now, with the added restriction of type)

We have just started working on this one, and would like to understand a bit more how you would use location based and task type custom fields together.

1) When you open a task would you like to see both the location based and task type based custom fields? or would you like only task type custom fields to show when you open a task with a custom task type?

Answer> My primary use case was to allow for parent child relationships within the same list. So, for my use case, I would only want the custom fields displayed for the task type. For example, we use ClickUp to manage the software development life cycle. A feature is the parent task. The stories, tasks and bugs would be children to the feature. In ClickUp, you refer to these as task types. In my mind, I think of them as different record types with different business purposes and requiring different fields. My second use case is to share a task from a list in one space to a list in another space. In this scenario, the other list needs to display fields specific to their list for the task. My home list doesn't want to see or know about their fields. So, in this scenario, the custom fields for the task template would apply to the task in the home list, but the custom fields in the target list would apply. So, ideally, the solution would allow for a bit of a hybrid approach.

2) If you have specific examples where you would combine task type and location based custom fields and how you plan to use them, please share 😊

Answer> See second use case above. To add further color, in our software development, we create features for specific platform, but for some features, we create shared services that can be used across multiple platforms. So, our platform-specific SDLC process needs fewer fields for planning and decision making. Our global services specific SDLC process includes about 20 additional fields targeted for a completely different user audience. So, when I share a task with the global list, they need to use the broader list of custom fields, but we don't want to see any of those fields on the platform-specific list.

Finally, if you are up for a quick chat about task types and custom fields tell me as I'd like to dive a bit deeper to understand your use-cases 😊

Answer>> Yes. I would be willing to have a discussion.

In my workspace all parent tasks in the CRM space are of the Type "Client" and should therefore have a buch of pre-defined custom fields that are specific to recording the details about a person, and this should stick no matter where the "Client" (i.e. task with task type client") is moved to. Similarly, I might add Meeting with Client as a sub task of the client (because it is quicker than task linking which involves clicking around much more), which would be of the task type "meeting", this should not display any of the custom fields of the task type "Client" even though it is a child of it, but like the type Client, should retain it's custom fields no matter which location it is moved to.

However, location custom fields are still needed. For example, I have a pipeline list within my CRM space, there are a bunch of fields which are not needed in other locations even within the CRM, but should be limited to task type, so they are location-based custom fields that only apply to specific task types in that location.

I really think for maximum productivity all the bases need to be covered rather than some half-baked implementation that isn't flexible enough.

Hi! I totally agree with the above and I suggest that we have the option to have the custom field set, applied either to, one specific task, or to a list, like it is currently. It will help when you have different kind of task in one list. With the current settings, to have the same custom field applied for the same category of task, we need to create separate list, which is not convenient sometimes.

I use this for school, and currently I have a Class dropdown custom field. I would like to be able to create custom Task Types of (for example) Assignment and Exam. The Assignment tasks would have a Link custom field to the submission dropbox but the Exam tasks would not. There are a few other examples I would use but they're all the same sort of thing.

I think it's important to have access to both the task type and location based custom fields at once, since they have complementary purposes and both are useful.