Set default field values for custom fields at the product level

We have a standard set of custom fields that we are inheriting across all products.  This ensure data consistency on how we describe features.  However for some products the field can be defaulted; For example we may have a product that has a feature that we have contractually committed to; so we have a field YES/NO.  However for another product it's less important and can always be NO.  Rather than set up custom fields for each product we love the inheritance but we want different default behavior so we can drive consistency of information to help reporting... Blanks are pains... 

  • Guest
  • Sep 12 2015
  • Future consideration
Release time frame
  • Attach files
  • Michal Anderson commented
    January 18, 2016 17:58

    The sheer abaility to just set a default value on a custom field is what I need.  Blanks are really a buzz kill!!

  • Marissa Melnick commented
    February 18, 2016 18:13

    Agree with Michael Anderson!  Just need the option to set a default value for custom fields!

  • Joe Carpenter commented
    March 16, 2016 19:18

    Voting this one up.  It's SUPER important especially given the inability for the report filtering to pick up on null values.  
    For us, we also are marking certain Products with 'Yes' and the assumption is that if it isn't marked 'YES' then it means no.  From an Aha perspective though, I can't set up a report to filter on the field such that is follows the logic "Show All records where (field) is NOT 'Yes'

    Thus, I need to go back to all the records, create a specific 'No' entry for that custom field, and edit ALL of the products.  Going forward, the field should always DEFAULTto NO, unless someone specifically changes it.
    Capeche?

  • Gavin Jones commented
    May 30, 2016 22:59

    Agreed - especially helpful in integrating with JIRA... certain fields in JIRA that are required, but from a product point of view need never change. 

  • Shri Iyer commented
    January 31, 2017 23:24

    Setting default values for custom fields at both the feature and requirement level is extremely important. We have to manually go and assign the value currently which is painful. Sometimes people forget and this then shows up in reports with no value. Please prioritize this.

  • Kai Schröder commented
    April 11, 2018 14:10

    This would really help!

  • Lindsay Hanrahan commented
    June 19, 2018 14:25

    We really need this.  It is driving our teams crazy, especially with certain fields we are trying to "set and forget" before they go over to VSTS.  We are having to build in additional layers of admin staff checking to confirm that these values are populated.

  • Brian Cunningham commented
    August 16, 2018 00:15

    The inability to be able to set the default value to any value other than blank/null, is causing us to create a non-intuitive setup for our global community of users. This design is creating extra work for us with training and will almost certainly lead to some confusion, misunderstandings, etc. Adding the ability to choose a default value, blank or some other value, will not only make data entry more intuitive but it will also make the filtering of the data simpler, and more intuitive, within Aha.

  • TrustRadius Infra commented
    August 17, 2018 22:22

    Can't believe this isn't in the product

  • Tom Gimpel commented
    September 07, 2018 14:48

    adding my vote. A default field value seems pretty obvious

  • Michael Anderson commented
    October 14, 2018 18:28

    Not sure if I am the original Michael Anderson or not, but I still really really really want/need this feature. Blanks are terrible!

  • Robyn Diamond commented
    November 26, 2018 22:03

    This is really important for syncing between JIRA & Aha as well because you can set the requirement in JIRA. It then rejects it bc Aha has no default value but JIRA needs the default.

  • Hannah Jackson commented
    12 Jul 17:11

    This would be super helpful in idea portal/forms as well.  

  • Deanne Branham commented
    02 Aug 15:06

    Need the ability to set the default fields especially in integration with Jira.. We have a user field that Jira sets to None if it is not filled in.  We need to do the same in Aha so that if that field is not intentionally set, we can all be in alignment.

  • Brie Engelson commented
    27 Aug 14:35

    Hi Folks!

     

    My Team's Request

    • Eliminate or mitigate the need to manually set a certain field for every aha card on every roadmap

     

    Details:

    • My team uses many Aha Products / Roadmaps - these all connect to a Jira Project (around 20 at the moment)
    • We have a field that is used across all cards / tickets that sends / syncs between Aha and Jira (two way sync in Jira 2.0 with "Tags" type field)
      • Every Card that originates from Aha Product / Roadmap A has field=[tag1]
      • Every Card that originates from Aha Product Roadmap B has field=[tag2],[tag3]
      • ...
      • Every Card that originates from Aha Product Roadmap N has field=[tag3]  and so on
    • Other considerations:
      • Each Card could support additional tags as needed
      • Each Card could need to exclude a tag for extenuating circumstances (rare)
      • Each Card could need to create a new tag for new reasons

     

    Current Solution paths:

    1. Manually set this field for every new card created on a given Aha Product / Roadmap
    2. Bulk set this field for all historical cards / any missed cards (have not tested, but expecting this to be the case)
    3. Manually check once a week / once a month that no tags on a given Product are missing - if they are, use item 1 or 2 above.

     

    Ideal Solution path:

    • For a given Product, allow a definition of preset custom field values as needed
    • Allow a toggle for "editable" or "not editable" (nice to have, but at a minimum, would need it to be editable)

    Note - we would not be able to support this on a layout level - we have a layout shared across products, but the products need the separate defaults defined.

     

    Thanks so much!