About custom field types

Have more questions? Submit a request

47 Comments

  • David
    Comment actions Permalink

    Hi Jessie, thanks for getting back to me.

    I was asking specifically about the multi-line text field.

    I expect someone over there to know how much text is allowed :)

    0
  • Jessie Schutz
    Comment actions Permalink

    Hey David!

    I did a little digging on this (it's been a looong time since I've gotten this question), and it looks like the limit on the multi-text field is about 60,000 characters. So unless you're going to be writing a short novel, you should be fine. :)

    ETA: Bear in mind that approaching this limit will start to impact your Zendesk's performance, so I recommend that you avoid doing so.

    0
  • Esther
    Comment actions Permalink

    Hi, is there a way to create a ticket field in "Time" or "Date-Time" type?

    0
  • Diogo Maciel
    Comment actions Permalink

    Hi Valerie!

     

    While you can create date fields, time based fields are not yet supported (you can use free text as a workaround.)

     

    You can create a post on our product feedback forum with your use case and this might get implemented in the future!

    https://support.zendesk.com/hc/en-us/community/topics/200132066-Product-feedback

    0
  • Amanda Wagner
    Comment actions Permalink

    Is it possible to have a date field automatically populated based on another date field? For some of our tickets, we need to complete two dates Date A and Date B. Date B is always one week before Date A, so if we could cut out having to select the second date that would be helpful!

    0
  • J.Michael Wagner
    Comment actions Permalink

    Hey Amanda,

    Unfortunately you would not be able to utilize a trigger to set the date field based on another date field. 

    One solution would be to use a web hook in your triggers and notify an external service that would then update that field value. Some documentation on web hooks can be found here 

    You would be able to send the ticket field data in Date Field A then run some logic and make an API call to update Date Field B. Otherwise, the Apps framework may be another good avenue to extend this functionality. 

     

     

    0
  • Andrew J
    Comment actions Permalink

    What is the usefulness of credit card numbers that are not stored?  How are these used?

    Credit card number This field allows users to enter a credit card number in a secure, PCI compliant manner. Only the last four digits are visible to agents and stored by Zendesk.
    0
  • Trisha Patel
    Comment actions Permalink

    Hey Andrew,

    A field cannot be PCI compliant if shows the entire number. It is a huge security risk to have the entire CC number available for anyone that can log into the account. If you did want to store CC numbers you can use a numeric field instead. 

    0
  • Karen D Snyder
    Comment actions Permalink

    Has anybody had trouble with using regex for a field? We would like to have a phone number field, so I used the regex ^[(](\d{3})[)][ ]?(\d{3})[-](\d{4})\s*$, which allows (xxx)xxx-xxxx or (xxx) xxx-xxxx. The regex works in rubular, and works in the Preview when setting the ticket field. But when I test it in the ticket form, there is no validation; I can type any character in the field. When I inspect the field HTML, I don't see any validation:

    0
  • Dan Kondzela
    Comment actions Permalink

    Hi Karen!

    This is quite a conundrum. I just wanted to post to let you know that I am creating a ticket for this request. You'll hear from me via email shortly!

    0
  • Dustin King
    Comment actions Permalink

    Are numeric fields really restricted to 12 digits max as this article says? I've been testing some custom numeric fields with larger numbers the data seems to have been stored properly, as far as I can tell. Is this restriction only when customers enter info in a relevant field on the form, or am I missing something?

    0
  • Brett - Community Manager
    Comment actions Permalink

    Hey Dustin,

    After doing some testing as both an end-user and agent on the account it doesn't look like theres a 12 digit limit any longer for custom numeric fields. I've tested well over this limit without any issue. I'll reach out to our documentation team here to see if we can get that information updated in this article.

    Thanks for letting us know!

    1
  • Andrew Checkley
    Comment actions Permalink

    The Regular expression example.

    Here's a regular expression for a U.S. social security number: \b[0-9]{3}-[0-9]{2}-[0-9]{4}\b

    Is different to the example shown in the screen shot showing the product ID which causes confusion. Was a while before I noticed when trying to figure out how to use this field type.

    Thanks

    Andrew

    1
  • Nicole - Community Manager
    Comment actions Permalink

    Thanks for pointing that out, Andrew. We'll have the documentation team take a look.

    1
  • Rob Stack
    Comment actions Permalink

    Hi Andrew, many thanks for this great feedback. I've replaced the screenshot with an example of the SSN format. I hope this makes this clearer and thanks again!

    0
  • Panayiotis Pantazis
    Comment actions Permalink

    According to the table, we were expecting the Decimal field to support only numbers and decimal points 

    Decimal

    This is for numbers that contain decimals.

    However we've noticed recently that comma's are also accepted and causes us a bit of hassle when exporting this field. Has this always been the case? What was the rationale behind the comma logic despite the guidelines above?

    The only other reference to this is an article (https://support.zendesk.com/hc/en-us/articles/360000183407) discussing how this interacts with Zendesk built-in reporting.

     

    0
  • Brett - Community Manager
    Comment actions Permalink

    Hi Panayiotis,

    Comma usage as a decimal separator is common within European countries so we allow both to be used in a decimal field.

    Unfortunately there's no way to toggle this off but I do hope this clears up any confusion.

    Cheers!

    0

Please sign in to leave a comment.

Powered by Zendesk