Custom Fields - Global and Specific

Building further on Custom Fields, presently implemented on a global basis, would be the ability to define Custom Fields for specific Organizations, Groups, ... It gets quite un-Zen like to have non-applicable custom fields clutter up the place.

The tag based implementation of Custom Fields integrates well with Trigger Rules to enable some useful mappings between Custom Fields and Ticket Fields e.g Critical [Custom] maps to Urgent [Priority]. This lets users communicate more that just a description of the request to include metadata.

A step further, is to make Custom Fields specific to scenarios. This would enable implementation of SLA's where customer Organizations use particular terminology not applicable to all Organizations.

I guess there are  two aspects for implementing this: (1) Global Custom Fields, & (2) Context Specific Custom Fields.


  • 0

    We understand what you want. But not sure if we should add this layer right now. The SLAs are going to be organization-specific though. That's for sure. No ETA yet.

  • 0

    This is quite important, we need that ability to set-up Custom Fields as implemented with Tags on a global and per Organization basis.

    My reference to SLA's is in the holistic sense of agreed terminology, but it's equally important that the QoS is measured by the SLA functionality provided by Zendesk. This is a standout feature and prime motivator for using Zendesk.

  • 0

    For us this is an important thing as well. We have customers (organisations) with different service objects. (website 1, website 2, application x, etc). A ticket must be connected to an service object (for billing, reports etc). Is there a way to work around this?

  • 0

    Any change of mind in regard to including this in the next set of custom field capabilities?

  • 0

    We want to get custom fields out in the wild, in order to get feedback for the basic functionality. Organization specific custom fields will not be part of this first iteration.

  • 0

    Basic functionality works well, particularly as they are implemented behined with tags so that rules can be created.

    Like the options to expose at two levels (user selection & visibility)

    As mentioned elsewhere, we need a re-ordering capability this is probably the most pressing in terms of the initial implementation. Free Form & additional hard attributes are also covered on different topics.

    The layout control of these custom fields may need to be thought about more. When you have several sets of custom fields in can get confusing, especially as some might not apply (granted this is caused by the custom fields you set up).

    Would like to use more custom fields but these tend to be more specific to particular types of tickets. Re the above point of complexity, maybe macros play a role here, so that you can apply the appropriate set's of custom fileds for the type of ticket or context of the ticket. In this way, you leveraging an existing capability rather than having to create another configuration control.

    Applying this to my use case for Organization based custom fields and I'm also now thinking about Groups based custom fields, I can see that it would also be more flexible to have additional rules Actions to call these macros that add specific custom fields.

    So, I'd be happy to re-phase this feature request away from Custom Forms for Organizations for new/enhanced generic capabilities:

    • Custom Fields global/specific configuration

    • Macro Action: Apply Custom Field

    • Trigger Action:  Apply Macro 

  • 0

    What about using the current tagging paradigm, adding tags via a trigger based on organization, maybe in combination with a macro?

    Frankly I don't understand your latest post, Graham.

  • 0

    OK, I'll explain further; some examples may help.

    • Documentation (Custom Field) - Missing, Minor Inaccurate, Wrong, Enhancement, ..

    • Software Component (Custom Field) - User Session Manager, Log4J, HTTP Client, Javascript, ....

    • Organization X Unique Severity Classification - Critical, High, Medium, Low

    The examples above illustrate specific custom fields that may apply to different scenarios, some may be specific organization based, others tickets type or as a result of analysis by the agent. In short, custom fields (enumerated list) enables a controlled & defined classification to be applied, as opposed to an informal folksonomy tag (not that there is anything wrong with this).

    Since custom fields are now available, the above can be applied. However, every custom field is applied to every ticket. This would be confusing if the custom fields types were too specialized. Hence the first capability enhancement request - enable custom fields to be global or specific.

    So, the next issue is how do we define which custom fields can get applied to each ticket, if it is not global. For some scenarios a simple trigger could be used i.e. for Organizations or Groups. For other scenarios, I'd see Macro's as being an excellent mechanisum:

    Suspect Bug > Action - Apply Custom Field X

    Sorry, I may have confused you with my original definition (Trigger Action - Apply Macro, should have read Apply Custom Field).

    In summary the new actions enable either an automatic (Trigger) or Agent selection (Macro) mecahnisum for applying a custom filed to Ticket instance.

    Does this help?

  • 0

    The latest custom field capability is great, even more ways to add custom fields. However, this can lead to further clutter as not all custom fields may necessarily apply to all tickets (certainly in our use cases we'd like to have custom fields per Ticket type and even per Organization).

    So, to recap, we'd first need a property on custom fields to signify specific or global. Secondly we'd need a new action on a macro which would add specific custom fields to Ticket instances. The concept behind this, is that it leverages existing methods and increases flexibility.

  • 0

    agents already have "triggered" or dynamic fields for incident and task types
    so it would seem zendesk already has the framework for this

    i don't think i would benefit that much from organizational specific fields but certainly could use some method for dynamic fields on the user page

    if anything then those that wanted per org fields would just have to define a unique field and associated unique function call per org

    so whoever that is would have to decide if that is worth the effort in their design


    you've got some great framework!

    keep making it better!

  • 0

    Hi Ted, as you say, you may or may not see specific benefit for specific custom fields, but these should be framework based.

    My original suggestion was to cover one initial use case (custom fields per organization), but the more I thought about it, the more I could see a need in other areas.

    I've suggested a design solution that perhaps offers the most flexibility by enhancing the framework constructs, rather than on specific use case solution and avoid complexity in the administration UI i.e. one check box for specific/global custom fields & one additional macro action to apply specific custom fields to ticket instances. How this is all implemented underneath is another matter :-).


  • 0

    Any update on plans in this area? I would really like to see this added flexability.

  • 0

    Is there any ETA on when custom fields under Organizations will become available? 

    We want to move away from our existing system, but there are about 8 fields of data today that we reference frequently for each customer, and ideally, we would have this information available, and displayable via a widget from inside Zendesk whenever we are looking at a ticket.  So we would need the API to allow us to easily reference this data as well.

  • 0

    This request is some thing that would be very useful/important in our implementation also. 

  • 0

    I would like to echo Graham's request as this would be beneficial to us as well.  It would be great to define the display of custom fields (view/edit) at the organization level and the group level; or even, the ticket type level. 

    Even better would be the ability to map one custom field to several others that are specific to that custom field.  Lets say I created a custom field for "Category".  If one of the options in this custom field was "Issue on Website", that could display several other fields, such as "Frequency", "Platform" and "Browser/Version".  Another option under the "Category" custom field might be, "Login Request", which could expose custom fields for "Permission Level" and "Advertisers to Assign".

    I also agree that the way the custom fields are displayed can quickly get a bit unwieldy, even if we were able to limit certain fields from displaying under certain conditions.  I would like to see more control over how these fields get laid out.  Perhaps, allow us to define that fields 1, 2 and 3 appear on row 1; fields 4 and 5 appear on row 2; field 6 appears on row 3; even if today, all 6 fields could fit onto one line, scrunched together.  What is also interesting is that the end user view doesn't display the fields the same way.  I'd prefer to see consistency, to the tune of what I am suggesting above for both end users entering tickets as agents entering tickets on their behalf.

    Is there anything like anything suggested above that is on the ZD roadmap?  If so, when?

  • 0

    (cross posted from a similar topic)

    We have developed a complete set of conditional field capabilities than are quite sophisticated in operation, this includes conditionally revealing fields and field combinations, depending on custom fields, system fields, and people (person & organization) related fields. We also ensure nested selections are cleared when new selections are made and also detect and trigger on events such as changing the requester.

    Drop us a line via https://support.zendesk.com/entries/23429-coherence-design if your interested in exploring what we can support you with.


  • 0

    I read a lot of great comments about the feature which is missing in ZD. It would be very useful. It would be great that ZD would add it in the near future because we are planning to use ZD in IT support environment  where specific Organization should see only dedicated customized fields in "submit request page". 

    Thank you.

  • 0

    I like the product, but it needs some extra features to achieve the needed flexibility. Now every agent sees the same fields, and every end-user sees the same fields.

    ZD has a very plain basic forms view, this is one of the main reasons we haven selected it for our support desk. We where planning on creating Agent accounts for our external support teams as well. But this would mean they see all the custom fields we have created.
    We have custom fields regarding billing, deadlines, etc. these fields are not to be edited or even seen by external agents.

    If it would be possible to select visibility on group membership or organisation. The flexibility of ZD would be greatly expanded.

    And we could upscale our support desk


  • 0

    I would also like to echo this suggestion. Government regulations require vendors to verify to have mechanisms in place to verify that whenever a Federal employee submits info to that vendor, that Federal employee must verify that they didn't send any classified info.

  • 0

    Still new to Zendesk but not to support systems.

    Zendesk is very well designed and simple. It is really a pleasure to see it in action, congratulations.

    To echo some of Graham's posts and others, I would say that a great improvement to Zendesk would be the ability to define custom attributes for what you call "People", ie endusers, admins, agents, groups or organizations. If defined as tags, then all these new attributes could be used in rules for Triggers or Automation.

    A key example is the following and I am sure it is a classic in many support operations. It has been everywhere I have been so far.

    * A customer buys a software license or subscription with a support contract defining a certain SLA based on (1) priority levels, (2) max response-time for each priority level, as well as (3) hours/days when you can contact support. These are the three usual key elements of a support SLA.

    * What this customer has bought is part of the "Entitlements" of this customer. These are typical info that we should be able to store in Zendesk custom fields, at Organization level (if a unique SLA for the whole organization) or even at User level (if a particular user has a specific SLA, edge case...).

    * Once stored in custom fields at the right level (depending on our operational requirements), we would be able to define all the triggers and alarm to manage (and prevent) our SLA breaches.

    * A cleaner way to do it would be to implement a normalised data model where you would define a new data entity in Zendesk, ie "SLA" (like tickets or people today) and for each Organization, you would define what SLA this organization is entitled to.

    Well, one way or another, I hope that you will do this asap. Allowing the creation of custom attributes/fields for the "People" entities would be just GREAT!

    Thank you and keep up the good work.


  • 0

    It would be helpful to at least have an id attribute on custom field div tags.  Then I could use some simple CSS and JS widgets to show fields when I want them.

  • 0

    Hi, a quick suggestion:

    Is it possible to get DIVs around custom fields?

    as we are now allowed to edit the CSS in the advanced settings, we could have custom Dropboxes by just hiding (some) fields in one dropbox or another.



  • 0

    With our recent increased usage of the Zendesk system (2000+ tickets per month) we have a need to track the tickets by a custom field called 'Request Type'. This field has two types of options that are available and we do not want to combine them into a single select list, but rather have two lists that we can maintain.

    We could add these as two separate fields, but agents are required to fill these fields out prior to Solving them, which would force our agents to select an item in both lists instead of just the ones that are applicable to their group.

    Is there a way to make a custom field visible and/or required for a single group instead of being visible and/or required by all groups?


    This feature request seems to be the only feature request for this, is this in the pipeline or should we try to find another workaround?

  • 0

    We are planning to address this use case (partly or in full) in 2012.  As a result, we are looking for passionate customers who want to help us gather the right requirements for the development of the feature.

    We need your help because to do it the Zendesk way, we need to know what you care most about (and what you believe is a nice to have). Participating insures that you and your company have a voice in this important feature. Your required involvement is minimal. We are planning to have 1-2 surveys and set up a private forum where we can all exchange ideas and information.

    If you are interested, please  register here.

  • 0

    Hi Pierre,

    any news on this item?


  • 0

    Any updates on this? I thought  release was coming on this.

  • 0

    We need this too.

  • 0

    Hi all,

    We have started work on a feature we're calling "Ticket forms."  This feature would allow admins to designate different forms that contain different fields in them.  Both agents and end-users (depending on your settings) would be able to choose the form for each ticket.

    We are working toward having a beta for ticket forms within the next 3 months, subject to change (in either direction).  I will be posting the formal invite to the beta in this forum when we're ready!


  • 0

    +1 for permissioning field visibility by agent level/type. For example, we don't want our Tier 1 agents to be able see/edit the custom checkbox which alerts our COO to a critical situation. That functionality should be limited to higher-level agents and managers.

  • 0

    Any updates on this?

Please sign in to leave a comment.