# Custom Groups in Workflow **URL:** \ **Category:** Ideas & Features\ **Created:** [March 26, 2025, 6:01am UTC](https://community.fibery.io/t/custom-groups-in-workflow/8516 "2025-03-26T06:01:49Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![njyo](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/njyo/32/923_2.png) [@njyo](https://community.fibery.io/u/njyo)\ **Post date:** [March 26, 2025, 6:01am UTC](https://community.fibery.io/t/custom-groups-in-workflow/8516/1 "2025-03-26T06:01:49Z")
When tracking Workflows it would be very helpful to be able to add custom groups. The `Not started`, `Started`, `Finished` default groups are neat, but it would be amazing if we can change or expand them: ![2025-03-26 at 13.54](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/9/9de0a4da49d3644cef418ed550c27c5aca41f2bd.png) Here is our states in our product backlog. I would want to be able to have the following groups: 1. Blocked 2. Defining 3. Developing 4. Testing 5. Releasing 6. Live 7. Abandoned Most of these groups would have 1–3 sub-states. I can also imagine other workflows like approval processes and other to be wanting to support custom groups. I think that can still align with the `isStarted` and `isFinished` functionalities that you already have, but it might require a little re-jigging. Thanks! ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [March 26, 2025, 6:58am UTC](https://community.fibery.io/t/custom-groups-in-workflow/8516/2 "2025-03-26T06:58:50Z")
The existing groups are basically just hardcoded valies in a text field. If you want your own categories, you can add a custom text field to the workflow ‘db’ and set the values appropriately. The UI won’t be the same as the native groups, but the functionality will be. ---
**Author:** ![njyo](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/njyo/32/923_2.png) [@njyo](https://community.fibery.io/u/njyo)\ **Post date:** [March 26, 2025, 8:12am UTC](https://community.fibery.io/t/custom-groups-in-workflow/8516/3 "2025-03-26T08:12:44Z")
Thanks, @Chr1sG, I’ve already added my own fields in some places, but as said, it would be neat if the `Type` would become a sorted single-select itself, so that the UI can also support it. ![2025-03-26 at 16.10](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/9/902811a456add15cd2b508c07f07499c6610656b.png) ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [March 26, 2025, 9:15am UTC](https://community.fibery.io/t/custom-groups-in-workflow/8516/4 "2025-03-26T09:15:08Z")
Yeah, so select fields (like the workflow) can’t themselves have select fields as properties. I think if you need more than the ‘basic’ fields that a select database supports, then you would be better served by using a ‘full’ database instead of the workflow/select field. There are obviously some differences in the behaviour/appearance of a select field and a man-to-one relationship, and there are a handful of discussions about these and related things, e.g. > [@Set anything to be "Final" workflow](https://community.fibery.io/t/set-anything-to-be-final-workflow/8507): > > I don’t really like working with the Workflow field as it doesn’t really treat it as a database when it comes to automation and such. But the grayed out entities and the “Include Finished” in search make it quite nice. It would be nice to be able to scope any field named “Final” with a checkbox (on the entity, using a lookup) and give it the grayed out colors. Even better would be to set custom colors filters globally, not per view, plus custom filters on search. But that might be trickier? Not… > [@Convert select fields into regular databases](https://community.fibery.io/t/convert-select-fields-into-regular-databases/6629/8): > > The one advantage that simple single/multi select fields have is that for the most users, they just show up as drop-downs which are easy to use and understand. Relations to entities (one-to-many or many-to-many) have a much more sophisticated rendering and can sometimes confuse users, especially the ability to drill-down into entities: Things are even worse when it comes to multi-select relations: It would be amazing if a “Display as” option was provided whereby you could b… > [@Global single and multi-select field options](https://community.fibery.io/t/global-single-and-multi-select-field-options/2779/9): > > Per the suggestion, I’ve gotten in the habit of using databases in many cases instead of single/multi select fields. However, there are a few pain points with this, mostly on the UI front: single/multi select fields can be colour coded and have an icon (though the icon issue I think is already resolved) single/multi select fields have a very simple display both in the entity view and on other views, whereas relations confuse users because they show up with database icons and the “\>” button wh… but if these issues were resolved, I don’t see many drawbacks of using a db.