🏷️Properties

Doc types come with built-in properties, but what if you want to filter feedback by type, bugs by browser, or feature requests by product area?

Custom properties let you do just that. Create & edit custom properties to make your Cycle workspace work as you do.

Table of content

Create a custom property

Learn how to create a custom property by following these steps:

  1. Open your workspace settings & navigate to the "Properties" section.

  2. At the bottom of the properties list, click "Add new".

  3. Give your property a name, type, and color, then hit "Save".

  4. Next, link your property to one or more Doc types

Voilà!

You can always edit the linked Doc types by clicking on them. Using the "..." menu to the right of a property will let you duplicate or remove it.

The interactive demo below will show you how to create a custom property for your feedback docs.

Additionally, you can also create new properties when editing a Doc type. This is useful if you prefer to set up your workspace one Doc type at a time.

Sometimes a custom property should be shared across multiple Doc types. There are two ways to achieve this:

From the "property" section of your workspace settings

From the "Doc Types" section in your workspace settings

Properties' suggestions

Here are the properties created by our power users and ourselves. The goal is to inspire you, you'll probably not use them all on a weekly basis.

Feel free to adapt them to your needs. They are in line and compatible with the views suggestions and the workflow's suggestion.

  • Priority or Importance (High, Medium, Low)

  • PM or Squad or Team

  • Component or Product Area or Product line

  • Complexity or Effort (S,M,L)

  • Internal resource (URL)

  • Quarter or Time horizon (Now, Soon, Later)

  • Feedback type (default)

  • Customer type or Persona (default)

  • Impact (High, Medium, Low)

  • Sprint

In context property update

You can update properties on the fly – no need to go to the settings to edit an option, do it right when you need it.

This works: ✅ When you create a new insight ✅ Inside any doc ✅ From a view

Property inheritance

Feedback > Insight > Docs

When a property is shared between Feedback, Insight, and Feature, it will be inherited from Feedback to Insight and from Insight to Feature.

Watch the magic happen in this video. 🦹🏽

Top-down inheritance

Imagine that you have the following structure: Problem > Feature > Insight.

When you'll update the property of any problem, all the features that are nested within that problem (as well as their corresponding insights) will then inherit from the same update.

There is a difference between whether the children are insights or any custom doc (eg: Feature).

  1. If you have Problem > Feature: your Features will only inherit the Problem' s properties if the Feature' s properties are not filled in. If you tagged previously Product Area X the Feature, it will not be updated.

  2. If you have Problem > Insights : your Insights will always inherit the Problem' s properties. If you tagged previously Product Area X the Insight, it will be updated.

Always, let's mention that this inheritance only happens if the property is shared between the doc types. In the example below, Product area is shared between Feature 🌱 and Insights so inheritance will happen. Effort though is not shared with Insights so Insights will never get this property.

Last updated