Field Types#

The following is a list of the field types we use internally. Normally, you'd choose one of these fields when creating your action fields or trigger fields via the type dropdown:

field types

However, if you're using Custom Fields you might want to know the available field types. The key column corresponds to the type key found in the code example here: Action Fields (Custom).

Unicode#

Unicode fields are essentially one-line text fields that can support unicode characters. There is no coercion done for this type.

Unicode fields are represented by a type: unicode key.

Textarea#

Think of this as a multi-line unicode field. It's really only used to give the user a textarea in the UI instead of a one-line input field. There is no coercion done for this type.

Textarea fields are represented by a type: text. key

Integer#

Suitable for whole integer numbers, we'll coerce any text down into an integer by stripped non-numeric values from the string. A negative sign (-) in front is also allowed.

Integer fields are represented by a type: int key.

Float#

Like integers, this will coerce any text down to a floating point number with the addition of allowed characters like . and ,.

Float fields are represented by a type: decimal key.

Boolean#

We apply some natural language parsing to try and coerce any text into True or False. This UI field is also replaced with a dropdown allowing the user to specifically pick "Yes" or "No" explicitly.

Boolean fields are represented by a type: bool key.

DateTime#

Our most complex coercion. We'll attempt to convert any given value into an ISO-8601 formatted string. The parser is quite robust, supporting epoch timestamps, ISO-8601 and even natural language parsing! You can use moment.js via Scripting to parse and replace if your servers expect a different format sent to it.

DateTime fields are represented by a type: datetime key.

Dictionary/Object#

This is a fairly complex shortcut to a widget that allows a user to provide a series of key/value pairs, perfect for providing completely unstructured and custom metadata (do not use this if your API provide definitions for that metadata, look into custom fields instead!).

Dictionary/Object fields are represented by a type: dict key.

There are also a few other special things, related to types, you can do.

Static Dropdown#

You can provide a choices array which will be mapped automatically into a dropdown in the Zap Editor. In the developer UI you should simply provide us with a hard-coded list of comma-separated values for the "choices" option when defining a field. If you're using scripting, you'll want to provide this array to us manually. Here is a code sample and what it looks like:

[
  {
    "type": "unicode",
    "key": "color",
    "label": "Label",
    "help_text": "Pick a color label to apply to the card.",
    "choices": ["none", "green", "yellow", "orange", "red", "purple", "blue"]
  }
]

field choices

You can also provide an object with key and value for choices if you like.

Lists#

Say you wanted to allow the user to specify multiple values for a single field. Maybe, a list of tags to apply or a list of email addresses to send to. You can use our list feature to enable "+" and "-" buttons in the Zap Editor which users can use to specify more than one value. list fields can be any type except dict.

You can make a field a list by checking the appropriate box in the UI. For custom fields, you can use Scripting to alter the field definition to include list: true like this:

[
  {
    "type": "unicode",
    "key": "to",
    "label": "To",
    "help_text": "Who will this email be sent to?",
    "list": true
  }
]

field list

↑ Was this documentation useful? Yes No
Get Help