How your team can use custom fields

In this episode of Workflow, Brian and Tom talk about custom fields. Why we’ve built them and how your team can leverage them.

00:40   What’s happening at Rindle (custom fields is launching)
03:38  What are custom fields?
04:55   Why we decided to build custom fields into Rindle
07:21   Examples of how they can be used 
22:05  Custom fields vs. tags
24:35  The future of custom fields
26:28  Tips for taking action!

Useful Links

Learn more about Rindle's custom fields

Brian: 00:00 This is Workflow, episode 14.

Brian: 00:14 Workflow is the podcast that helps teams figure out the best way to work, collaborate and get stuff done, brought to you by Rindle.

Brian: 00:29 Hey, everyone. I'm Brian.

Tom: 00:31 And I'm Tom.

Brian: 00:32 And we're the co founders of Rindle and this is our podcast Workflow. Today we're talking about custom fields, why we build them and how your team can leverage them.

Tom: 00:40 Cool. Before we get started with that though, what's going on Brian? Anything exciting happening in Rindle?

Brian: 00:46 In Rindle world?

Tom: 00:47 In the Rindle world. The world of Rindle.

Brian: 00:50 Yes, actually and this podcast topic I guess is very timely because we have by the time this podcast is released, officially launched custom fields, which is really exciting. I think we've mentioned it a couple times that we were working on it in previous episodes. So to see it come to life and you know, right now being in the midst of testing it and make sure everything's working properly, a really exciting kind of what we're going to bring customers.

Tom: 01:18 Yeah, definitely. I'm super, super psyched to finally get it out. I recently even tweeted about it, which is the first tweet I've had in a long time actually, on my personal Twitter account.

Brian: 01:31 Driving those twitter followers.

Tom: 01:32 Yeah. Feel free to follow me, you know, @TPlaner on Twitter. No.

Brian: 01:39 There are people flocking there right now.

Tom: 01:40 Yeah, I hope so.

Brian: 01:43 Well, I think the cool part about launching, you know, this feature because, you know, we just did a whole V3 kind of rework of our platform and all that stuff, so it's kind of fun to get back into kind of a faster cadence at least with some of these feature releases. And with this custom fields release we are actually kind of implementing a new product feature playbook, from the marketing perspective. So when we release this feature, we're going to be timing out emails and blog posts and social posts and things like that, even help desk articles. So it is exciting to kind of get that formally rolling in a better way, because we were working on V3 for a while.

Brian: 02:23 So it's kind of nice to get back into that mode and actually make sure we're actually promoting these things properly as well.

Tom: 02:30 Yeah. We're also able to get some like smaller ... Custom fields is obviously a big enhancement of the product or a fairly big feature, but we also have gotten some smaller, you know, features in there such as colors, like more colors. Basically, you can add in any color that you want for tags and list colors.

Brian: 02:51 Yes. And my favorite, which is the enhancing the copy feature, where you can copy a board and now it includes automations. Very awesome. So now you can have, you know, three, four or five automations on a board. You can use that as a template and copy it and all those automations follow it, which is awesome.

Tom: 03:11 So lots of stuff happening in Rindle.

Brian: 03:14 Absolutely. So before we roll into our main topic, if you have questions, topics, or team snares you want us to tear down, you can call 860-577-2293 and leave us a voicemail. Or you can email us workflow@rindle.com.

Tom: 03:29 And also if you, uh, if you like the podcast, please leave us a review. It helps us reach more people and it motivates us.

Brian: 03:38 All right. So onto the main topic. What are custom fields? So today we're going to talk about custom fields. We are launching the feature itself and our own platform, but other platforms do have custom fields and even different types of platforms have them. So we thought it'd be fun to talk about how your team can actually leverage them. Wat they are, different scenarios, how to use them, et cetera.

Brian: 04:01 Just to kick things off, custom fields generally provide additional context and in light of Rindle or any other kind of task or project management platform, they're usually within a task. So you can basically start collecting customer data sets if you will, within the task that might fit your work flow a little better than what's provided by default.

Brian: 04:23 So in our system we have, you know, a task title by default. We have a description area. You can add comments and all of these things, but if you wanted to add something else custom that had to be collected or tracked with each task, you can do so with a custom field.

Tom: 04:37 So we offer seven different types of custom fields. We offer a text type, a number, a drop down, check boxes, radio boxes and a toggle and then a date field.

Tom: 04:55 So we will be getting into each of those in greater detail in a couple of minutes. But before we actually start talking about them in detail, we should probably talk about why we decided to build the custom field into Rindle at all.

Brian: 05:11 Yeah, I think it all really started from customer requests. A lot of what we do, you know, is driven by our customer feedback and you know, it's just ... obviously it's popular in a lot of tools out there already. It doesn't mean that it's justified for every product, but you know, we were getting a lot of customers kind of asking for, "Well, how can I do things?" Like possibly tracking time or a piece of data that's custom to their workflow or you could be even an internal indicator of some sort, whatever it might be, you know, how can we get that into Rindle?

Brian: 05:43 And I think the answer right now, you know, before custom fields was, you know, well put it in the description fields, right? Or add a comment with that data in there or maybe attach a file with that information in it. So that really doesn't lend itself to being kind of conformed, easy to use in a lot of ways. And a lot of people were kind of cramming a bunch of pieces of data into description field which makes it hard to follow. It's not formatted properly at each task. It's always different. Those kind of things.

Brian: 06:11 So, that's when we really sat down and said, well, you know, we probably need to build something to give that to our customers and let them track the information they need to track easily.

Tom: 06:21 Absolutely. Yeah. And this is a pretty common bit of functionality found in a lot of project management softwares, I would say.

Tom: 06:27 It basically just allows you to extend the functionality, the core functionality of project management software to really suit your specific needs. And it really just gives you the flexibility to track exactly what your team needs.

Brian: 06:44 Yeah, and I think the flexibility is a key and I think a lot of our product at least is built with flexibility in mind. We're very workflow driven. We want people to be able to configure the workflows that they need, so in the same light, they should be able to configure the task to receive the data they need to receive, custom to their workflow.

Brian: 07:04 But I think overarching approach for Rindle at least is, you know, doing that in a really simplistic way. Can we offer the flexibility that our customers need, but do it in a simple way that is not complicated, hard to use, hard to understand, and still give what they need and the flexibility?

Tom: 07:21 Sure. Yeah. So in order to actually do that, we actually investigated how other products are doing this. We also did interview a couple of our customers that had requested this and kind of asked them exactly what their use cases were going to be with the feature itself. And then we mapped it out a bit and how we decided to actually build it, I think, is simple.

Tom: 07:53 Yeah, let's get into the details of that.

Brian: 07:56 Yeah. So the first big thing that might be even a little unique to our platform, but we did start out with a permission based custom fields feature. So it's not just kind of for everybody to use where everybody can add a custom fields. An admin actually has to turn that on for you to be able to add new ones and manage the actual custom fields available.

Brian: 08:15 So I think that aspect alone gives our users a little more control, because it is custom and you are adding things potentially to tasks, we wanted to kind of not make it a free for all and by doing a permission based kind of limits the access a little bit and give it a little more control.

Tom: 08:29 And I think the real major reason why we also decided to do permission is because our custom fields within our system are global, so you don't just add them to one board and they only appear on that board. When you actually add a custom field to the system, it has the option to appear everywhere within the system, which is great. You don't have to have it appear everywhere. But with that, you also have the option to remove it and if you do remove it, it will be removed everywhere in the system.

Tom: 09:06 That sort of destructive piece of functionality really requires an extra level of permission, if you will.

Brian: 09:17 Yeah, that's a good point about the custom fields being global. That definitely drove a lot of that decision making process. And on top of that, you know, a lot of flexibility route, you know, we actually did allow custom fields to be turned on for all tasks, so not only one situation scenario being you know, let's make the customer field available through the whole system and they can be applied to any board or boards, but we also gave the ability to make it a global custom field in the way that they will automatically apply to all tasks in the system.

Tom: 09:51 So yeah, so that really gives that extra flexibility, if you will, to really make Rindle exactly what you need.

Tom: 09:59 You can, even on a global level, turn it on or off on the task face, which therefore allows you to have the task face show exactly what you need, like everywhere.

Tom: 10:12 So if you're using say, story points, there are something called story points within your workflow. You could have that display on every single task, what it is in our system.

Brian: 10:24 Yeah, and that's on the task face. So it just really allows you to bring the custom data you're collecting and possibly bring it to the forefront so you can say, like you said, the story points field, actually bring it to the task face. So when you're looking at the board of all the tasks for that project or whatever you're working on, you know, you can see that data without having to drill down into the task itself and look at each task and each set of data.

Tom: 10:48 One of the other real decisions as to why we made it so simple was actually to get the feature out faster and then potentially iterate on it if we get actual user feedback that things need to change or people want additional types of custom fields. This is obviously what we attempt to do with everything that we create. But I think it's especially important with something like this, which does have a level of us flexibility and customization. Awesome. Anything else we want to talk about with our decision of how we decided to create it?

Brian: 11:25 No, I think that's about it. I think that gives some great background information as far as Rindle's concerned and I think we should go into some use cases of how you can use these custom fields, whether you're in Rindle or whether in another product.

Tom: 11:37 We have several types of examples. So I think the first type is an editorial type context?

Brian: 11:46 Yeah. Even in our own workflow, which I've mentioned a couple times on the podcast, but you know, we have a blog post board. We have a podcast board, where we manage kind of editorial content, and just some examples of how you can use custom fields for that type of content, blog posts specifically. Um, but one could be word count.

Brian: 12:06 So if you're working with freelancers and you're trying to communicate "Well, yep. This blog post is coming through the pike. It's now assigned to you ready to work on." And you want to communicate well, how long should this be? Again, it doesn't require a meeting or anything like that or having to find it in some comment or description somewhere. It's actually a field that is consistent on every single blog post that comes through the workflow.

Brian: 12:25 And you can simply provide, "Yep. This should be a 1500 word blog post." So word count's a great example.

Tom: 12:31 Cool. Yeah. Another example is keywords. So keywords for SEO for again, a blog post. You could just have a text field and a comma separated list right there. Easy peasy. Easy peasy. You like that?

Brian: 12:48 Yeah, I like that. So, the next one is type of content. So you could be writing actually, even like for our product release, we're writing multiple pieces of content around the same topic, right? So the release of custom fields. So you might use a custom field for a type of content. Is it a blog post? Is it an email, is it a social post? You know, what is this type of content just to give more clarity, because you might have sometimes the same type of task name, right, or level of effort that you're trying to do repeated, right? Because you're doing things multiple times for different mediums. So having the type of content will help kind of clarify again, further for the freelancer or the writer or whoever you're working with that hey, you know, it's this many words, here's the keyword to optimize for and here's the type of content we're building this for.

Tom: 13:34 And in the same breath, more or less, is the location of that content. Is this going on Twitter? Is this going on Facebook? Where are we posting it? Or is this a blog post for a website? Or potentially could be for another source. So, but more than likely, that would also be like a drop down type field, right, Brian?

Brian: 13:55 Yeah. Or even could be check boxes, right? Because you could have all the mediums that you normally post to, all the locations and then when you create the content or you create that task to be kinda delved out to whoever's going to do it, you can say that, hey, you know, this goes on check, check, check.Right? And that's just how you're communicating. It makes it really easy to communicate those options that you see it kind of without having to pull out a drop down, you know?

Tom: 14:16 Good idea, yeah.

Brian: 14:17 Maybe you're doing like multiple locations on one task. That's another way to work, right? It really depends on your workflow.

Tom: 14:22 Sure.

Brian: 14:23 Cool. The next use case are client onboarding and possibly even CRM. So you know, in the same light of kind of an editorial board, maybe you're know having clients onboard through a product, like even like Rindle, like we have customers onboard, right? If you're doing that process manually, maybe you have a high touch sales process and you have to actually map them through a six week onboarding process, for example. That is able to happen now with custom fields because you can track specific information. Even from a CRM perspective, you're now starting to track things specifically about a client. So one could be like the account type, right? So maybe just for reference purposes, during this onboarding process, you want to select what type of account this is. Is it an organization? Again, just descriptives about who the client is.

Tom: 15:13 You might also want to track specific set up requirements for that client. Again, this could be just in done a nice text field there a instead of muddying up the description or putting it in a comment that might get lost, you just have a field for specific requirements.

Brian: 15:30 And that could be unique to your organization, unique to your exact setup workflow that you have. You can even have a couple custom fields that explain the setup requirements, if you will.

Brian: 15:43 Another field that you can use is to track the main account owner. So maybe you're working with account management team or a salesperson or something like that where you want to, you know, have a dropdown potentially of all your sales people or account management people that you could select within the task itself and understand who that person is in case you need to contact him.

Brian: 16:01 And again, it's nice and organized and easy to read.

Tom: 16:04 Same thing with this next thing, which is the project manager that's on the specific client project.

Brian: 16:13 Yeah, I think we would have definitely used those probably in our agency days because we always had an account manager and a project manager assigned. You know, and those were pretty much the owners of the account or the project. So it would be helpful to have that kind of information available.

Tom: 16:29 Definitely. Another piece of really helpful information would be an email address or addresses of the main contact on the client side. That way you don't have to comb through your email or you don't have to comb through again, the description field for a piece of information like that.

Brian: 16:48 And maybe even phone numbers, right? You never know.

Tom: 16:50 Sure. Never know.

Brian: 16:50 Never know where that CRM comes into play, but yeah, email, any kind of contact information, probably.

Brian: 16:57 And another one could be notes, so maybe you have something, like in Rindle, we have a description field, but maybe you have additional notes or a specific type of notes that you collect every time that you want to label a certain way. It could be another, again, providing notes or information on the task level.

Brian: 17:13 Another general custom field is toggle custom field, which in onboarding example, you know, you could be onboarding a client onto a software platform. You could be working with the IT team that has to actually create the account in the software. So you could have a toggle saying account set up yes or no and have them flag yes or no, whatever it might be, to indicate that the account has actually been set up.

Tom: 17:36 Next set up example that we have is for development. So, story points, we had mentioned them earlier. Story points could easily be tracked within a custom field. For example, in Rindle you might have a number type custom field that you display on the task face and people can enter in the difficulty of the task.

Brian: 17:59 Yeah. Really, it could be any kind of point system. Story points, in an agile world, but you know, even in a dropdown, if you have a one through 10 scale, you can even use a dropdown and have one through 10 and you know, select your internal rating scale or whatever. It could really be custom to your workflow.

Brian: 18:15 Another example is in a development world, maybe you have a roadmap where you're actually tracking features like we do here at Rindle. But you're also tracking, well maybe you have a really long backlog of features, you're tracking which customers are giving you feedback. But maybe you're also doing internal voting or rating system on that as well.

Brian: 18:33 So you want to track, well, what is interesting, what do people think are the most important things and actually use a custom field to track that data and give some format. So, you could use a drop down in that case. Again, with, you know, a one through five star rating system as an example or however you want to do it, but you know, track kind of importance on a roadmap.

Tom: 18:53 And finally, feature type. Could be a drop down, could be check boxes, depending on however you have it set up. They could be like an app. This feature's for an app, a mobile website, or for multiple things potentially.

Tom: 19:08 If you made a check box you could, you'd be like, okay, this needs to be configured for a website and for the app, but it's not for the mobile.

Brian: 19:15 Similar to types of content in editorial workflow, right?

Brian: 19:18 These are like, types of features. So we could be building a feature that's specific for a mobile app or maybe for the actual web-based app or maybe it's an enhancement that that feature needs to be added to the website. Right? So just to kind of again customize your workflow, but to identify the type of feature you're building.

Brian: 19:35 Cool. So the next kind of use case example are just general things that could be used really in any type of department or team or anything you're working in, but the first one is priority. So this definitely works across the board, but you know, a low, medium, high priority is a real simple example. Of course, this can be customized to whatever, however you rank or however you prioritize.

Brian: 19:57 But again, a dropdown potentially would work really well, or even a radio button option would work well. But again, if you're using anything at the task level to track priority, a lot of times, you know, in the workflows we described, you know, you might have lists within your workflow where the tasks are moving left to right and you might prioritize them that way, but maybe you needed additional prioritization on the task level. And this is a great way to do that.

Tom: 20:19 Another general example might be an estimate versus an actual. So you might have two fields and you might be tracking hours for a particular task and you might have have one field that, hey, what's the estimate? And you fill that out prior and then, once the task is done, you fill out the actual field.

Brian: 20:39 And this can be used even beyond hours, like for dollars. You're tracking a budget. So if you're estimating how long a project or feature will take, your estimate versus actual can be tracked that way. Same with story points, like we talked about. You know, you might estimate it's two story points, but it ended up being five story points, right? Just to understand that on any kind of estimate versus actual is helpful to know what you started with and know what you ended up with.

Tom: 21:03 So another real general thing is approvals. This one's a pretty big one. So you might have several people have to approve a feature or possibly if it is like, say a budget type thing, budget approval, you might have like, oh, this has to be run by Brian and Tom, before it actually goes out. So you could have each their names on a checkbox and when they approve it, they could check it off. It's pretty straight forward, but pretty awesome.

Brian: 21:34 And the last one is time tracking and this is definitely ... Like, we integrate at Rindle here, you know, with some time tracking tools like Harvest, um, but now with custom fields you can even track time, so similar to estimate versus actual, you can actually have a time field. This could just be a number of fields where you just input how many hours were spent on it and that could just be added. And with our support for exporting, you can actually export that project out as a CSV and easily do a whole bunch of calculations based on that data.

Tom: 22:05 So, I think a common question that comes up when you have any sort of additional functionality is why should you use custom fields versus say tags? Or even, you know, the description field, right? Like, where do you make the jump to decide like, oh I should use custom fields over this other piece of functionality that a product offers?

Brian: 22:30 Yeah, I mean something like custom fields and tags, they both offer flexibility. And in most systems you can have as many as you want. You can have different combinations. So it does come up often, like, well, what should I use and why and how? Here's just kind of guidance of how to think about each, if the platform you're using or especially if you're using Rindle, you know, we have both tags and custom fields, but tags are more informal and let you add information with a combination of text and colors.

Brian: 22:59 Users typically can forget to add tags because it's usually a couple steps to get a tag added. You're relying on a user basically to remember, oh yeah, before I finished this task or before I move this along the workflow, I need to make sure I add these two tags to it. So it's a little more reliance on the user to get that data inputted.

Tom: 23:21 I think they also sometimes lack context that a custom field can have. The custom field typically has had some sort of description for the field or a name of a field. And here's the value versus a tag, which is just whatever the tag is. So you might not know that, oh, this is the status tag because it's just a general tag, lumped in with all the other tasks.

Brian: 23:49 Yeah, I mean custom fields are generally more structured. If you need like standardized fields inside your tasks, like tags, you know, you have one piece of data, like a tag is a tag. It's it. It's a piece of text and a color or whatever that tag system might be. But something that custom field you can actually collect information on every task as a default.

Brian: 24:12 So that information, like we gave examples of all the different custom fields we have, but it could be a series of checkboxes. It could be an input field for text. It could be capturing a number. So, there's a lot more flexibility as to what you want to capture and how you want to capture it. And you can standardize on that so it's all collected and presented in the same way as opposed to tags where it's like, well, remember to add it, it's kind of one dimensional.

Tom: 24:35 So yeah, so as we said earlier, we designed this and built this quickly and simply purposely, just so we could get it out into the product. But we do have plans for the future of custom fields, most notably automations.

Brian: 24:55 With automations, we'll basically be able to leverage data that's inputted or selected through the custom fields, so you can basically have it be a trigger or an action. So imagine saying, "Oh, you know, when this field has a value as a trigger," for an example or a certain value potentially, you know, "take this action." Or you know, vice versa, have this custom field be the action, right? So populate this field or select this field or even add a custom field. So it's tough to say exactly what that picture is going to look like. But our automation platform kind of generally in that way. We have to work out the details.

Brian: 25:31 But the power of that, being able to add your own fields with your own values and add automations to a workflow is mind blowing.

Tom: 25:41 Yeah. Especially potentially leveraging them on the action side of an automation where you might be able to make use of a field, let's say like an email address in order to actually send an email to that address. That could be really awesome.

Brian: 25:58 That could be really cool because now you could customize because right now we have like, you know, the ability to email a notification out, uh, but that's really based on the users that are already in the system assigned to the task, things like that or watching the task. But to be able to do that off a custom build, again, if you're using it as like a CRM and you're emailing a customer at a certain step and you want to automate that? Really, really flexible.

Tom: 26:21 Yep. Really looking forward to starting tackle automations in the next couple weeks. So.

Brian: 26:28 Cool. So let's talk about tips for taking action. So I think the first tip is just, you know, when picking a platform, if you're not already on one, having the flexibility of custom fields will definitely come in handy. I think, you know, unless your workflow is super simplistic, which is great if it is, but a lot of times you will find yourself wishing that, "Hey, I wish I could just add this field to be tracked, where everybody can see it and input some data."

Brian: 26:51 So definitely keep that in mind with all the points that were made today with the different workflows. Some of these might have sparked some ideas in your head. So if you are in the market for a platform, keep that in mind when making those selections.

Tom: 27:03 And if you are struggling with how to track specific task information, try out custom fields, if your platform supports it.

Brian: 27:10 Yeah, I mean like kinda like we mentioned before just with like if you find yourself shoving a lot of various data into things like-

Tom: 27:17 The comment.

Brian: 27:17 That aren't meant to handle it ... Yeah, like the comment and the description field and things like that, that's usually a sign that you could do that in a better way that's going to be clear for your team, for everybody to see the information they need to see. It would also give you the ability in something like Rindle to get that piece of data onto the task face even, so they can even see it a little clearer. So if you're finding that happening a lot, if the platform you're using already supports it or whatnot, you know, give it a shot and try to get your data a little more organized. It's gonna be better for your team overall.

Brian: 27:50 Well, I think that about wraps us up for the day. If you have a question for us, you can call it into our voicemail number at 860-577-2293 or you can email it to us at workflow@rindle.com.

Brian: 28:01 Our theme music is an excerpt from Thunder Rock by Magic Studio, used under creative commons. Subscribe to us on iTunes by searching for Workflow and visit rindle.com/workflow-podcast for a full transcript of each episode. Thanks for listening and we'll see you next time.