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.

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.

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?

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

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.

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 
  

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.

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?

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.

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!