This is a public Idea Center  publicRSS

Idea

    114 liked this

    [Under Consideration] Allow Pick Lists & Hierarchy...
    Idea posted June 24, 2009 by Chris MartinMaster, last edited October 17, 2014 by Vimal ChopraApprentice, tagged System Admin and Configuration 
    352725 Views, 63 Comments
    Title:
    [Under Consideration] Allow Pick Lists & Hierarchy Structures to be custom field types
    User Story / Description:

    Concept:  Allow Pick Lists and Hierarchy Structures to be custom field types.

     

    The reasoning behind Pick Lists (which are menu's that allow you to select multiple items) is that often choices are not Mutually Exclusive.  For example, we use custom fields to control which interfaces out KB content should be available too; instead of having 5 yes/no custom fields for each interface, it would be great to have 1 custom field that we could simply check off the interfaces the content should be available too.

     

    The reasoning behind the Hierarchy Structures (similar to products/categories) is to provide more granular detail on selections.  For example, if we want to use dispositions as a general concept of what general activity was used to resolve the issue, our product team still wants to know the specific issue that caused the problem; so having a very granular hierarchy selection to further define what bug/issue the incident was related to would be very helpful.  A second example - our tickets are escalated often to different departments, but the initial Customer Service person is still 'responsible' for the ticket.  We have an 'Owner' field, but it is a single manually controlled drop down menu that gets very long, as it contains all of the names of people who could be 'Ticket Owners'.  Being able to replicate the 'Assigned' drop down menu with a 'Group/Staff Account' like structure would make for much better usage.

     

    ~Chris

    Comment

    • Kristie

      We would definitely find this useful as well. We currently have three fields titled Reason #1, Reason #2, and Reason #3 with the exact same list so that we can select more than one reason for the incident. With the pick list, we could consolidate these three fields into one field. I can also see the benefit in being able to have custom fields that have a heirarchical structure.

       

      Kristie Nelson

    • remco

      Very useful, we've got similar fields (6 codes to address the contents of a complaint) like the reason fields Kristie mentiones. 

       

      I would like to add the option of multi levelling them like the product/category fields. This makes search for the agent that much faster.

    • ihays

      It would be great if we had the ability within the Custom Fields, specifically the Menu Type, to be able to add Sub Menus for each item in the menu list.  I just got a recent request for this on a custom field and unfortunately I don't have the ability to do this with the Custom Fields.

    • eleep

      Hi guys,

       

      Just wanted to let you know that I edeted the Idea subject line edited to be more specific. Also, please try to follow the "one idea, one post" guideline for future reference.:)

       

      The reasoning for encouraging specific subject lines and the "one idea, one post" guideline is so ideas doesn't morph into one massive, all-encompassing idea like "re-write business rules" or something. :smileyhappy:

       

      You can review the complete Idea Submission Guidelines here.

       

      Thanks a bunch!

      Erica

    • NoahMiles
      We LOVE this idea!  We have so many places where we have created multiple custom fields to solve this problem that I can't count them.  This functionality would eliminate half or more of our custom fields, which would make creating and maintaining reports way easier.
    • Fougere

      Totally agree. The pick-list type is long overdue. It is a very common data-type and we could use it for sure rather than having to use multiple fields in its place...

      Same for hierarchical. We have a use for this as well which would allow us to do a major upgrade to one of our interfaces..

    • KmH

      Big kudos from TomTom as well. Pick-lists will add new possibiltiies also when integrating with other tools which make use of pick-lists.

       

      At this moment, we are pushing back any business requests requiring multiple custom fields which should instead be pick lists as we cannot account for all the extra maintenance required by those custom fields.

       

      Kind regards,

       

      Karim Michael Hambach

      TomTom Sales BV - Amsterdam

    • ChrisW

      And another.  I really (really) don't want to put multiple identical fields on workspaces when one will do the job.  Any chance we'll see this in a near-future release?

       

      Chris

    • jackadams

      Is this anywhere near a roadmap?

    • eleep

      We had a couple duplicate ideas requesting this same feature and include some good details/discussion on this functionality.  In an effort to consolidate voting and discussion in one place, comments have been closed on these duplicate ideas.  However, you can review these ideas and their comments for additional insight into this feature request:

      Thanks,

      Erica Leep, Community Manager 

    • Andrew W

      This is a must for functionality in future releases - it would help me out enormously - and so much easier and effiecient than any workaround. Please implement :)

    • ChrisW

      Hi RightNow,

      How do we keep track on ideas like this and know both IF and WHEN you will be delivering these items?  This one has been on my 'little list of annoyances' for a while now and i'd love to cross it out ;0)

      Thanks!

      Chris

    • Stephen Pickett

      I second this idea.

    • xwrjdl

      Great idea! I just recently ran across this limitation when considering how to tie a custom incident field to a rule so that one or more persons could be notified when the incident is updated.  We'd have to setup specific combinations are pre-set selections and tie them into a rule/function. Or, as has been mentioned, setup multiple fields.

    • Matt Potter

       On Behalf of Sarah Blocker,

       

      Multi-Select For Menu Item Fields
      Idea posted March 25, 2011 by Sarah Blocker , tagged Agent Desktop, System Admin and Configuration
      106 Views, 1 Comment
      Title:
      Multi-Select For Menu Item Fields
      User Story / Description:

      Idea:  Allow the ability to multi-select menu items as a config option for custom fields so that you do not have to make multiple copies of the same menus or tons of y/n fields to capture multiple inputs for the same type of attribute. 

      Examples of business need:

      1.  We work with orgs that have a presence in more than one of our regional markets.  We want to indicate where this org has presence (rather than create Org Name # 1 - Chicago, Org Name #2 = NYC, etc).  Ease of use would be create a standard menu where all applicable metros can be selected (i.e. Chicago and NYC).  Current constraints mean we have multiple y/n fields (Chicago metro: Y/N, NYC metro: Y/N).  We have 65 metros.  It's a lot of custom fields to build and maintain, plus our field staff HATES how cumbersome it is to update regional profiles.  Having one menu with multi-select would be a signifficant value add.

      2.  When collecting competitive intelligence, we want to be able to note if a target B2B client is working with other providers.  In the nature of our business, it's not uncommon that clients have non-exclusive agreements with more than one provider, so we've created multiple carbon copy menus to list our key competitors so that we know Client A works with Competitor 1, 2 and 3.  Having one menu with multi-select would allow us to keep a standardized list (for ease of reporting) while eliminating the need for mutliple, identical menus. 

      Anyone else out there having similar usability issues?  Thanks!

      SB