✏️ How do you feel about custom fields for open text entry?

One of the key change management hurdles I've encountered when migrating teams from basic spreadsheets for project tracking is the use of cells for capturing text input like a description of the current project status, next steps, etc. Some people are just more comfortable seeing it all in the table view rather than clicking into the detailed task view.

Only admins are allowed to create customer fields, and to avoid custom field clutter, I've been pretty adamant with our stakeholders about only creating a custom field if it meets any of the below requirements, which a text field wouldn't apply for:

Do we need to filter, group, or sort by this field?
Do we need to report on this field?
Do we need to create an automation triggered by this field?

Now that we're a year into our Wrike setup and admin, I think we can handle the introduction of open text fields from a custom field governance perspective, but I still feel like best practice may still be to use the task description and/or comments for those types of updates.

Do you use open-entry text fields or are you team task description?

Find more posts tagged with

Comments

Philip McKay

We have the same dilemma.

We do use some free text custom fields for things like customer surnames. That probably meets your criteria for filtering.

We also use them to capture a summary description of the project, particularly for project types like Committee Reports. A short paragraph summarising the purpose of the report is helpful in creating reports and dashboards that are then shared with non Wrike Users.

It is a difficult balance though.

Maryam Kadiri

This is an interesting conversation @Claire OWEN-SCHUBNELL. In my org, the Wrike Admins are responsible for creating all fields. If a new field needs to be added, a request form is submitted and we pretty much access its relevance against the criteria you highlighted above.

We use a good number of open text custom fields like description, comments, notes, summary which allows different teams pick suitable ones. Definitely being able to see description in the table view is a plus for us as you get all the information in one view.

Basically, our major governance is to ensure only account admins can create new fields. And we have provided a good number of open text fields that users can select from.

Jessica Bargenquast

We've been moving more towards Custom Item Types (CIT) so we could eliminate certain custom fields. For our new CITs we can then choose which custom fields show up on the CIT so it never looks cluttered or overwhelming. This also makes reporting a lot easier.

If your team is used to writing in text fields you could still have those custom fields and just pull the ones you need into a CIT so users are only seeing the fields you want them use.

Shona Snowden

We used to have only very brief text custom fields, but recently had to create a new report which needed a description field. It's working well, with the biggest issue being some people getting carried away with length... We also only allow account admins to create new custom fields.

Amy Hunter

Hi @Claire OWEN-SCHUBNELL, similar to @Maryam Kadiri we only allow Wrike Admins to create custom fields and we require a use case for any new fields added. We do have open text fields for requester name but most of of our fields are multi or single select and often linked to our request forms. I add open text fields if it's something that the team would benefit from seeing in the table view or need to easily report on.

Our task and project summaries are all included in the description field which has been working for us so far.

It helps that only admins are adding fields and we do an audit of custom fields every quarter.