Custom Fields

In addition to our built-in field types such as items, text, or column types, you can now build your very own!

The “Field Type” Custom Block allows you to create and reuse your configuration fields in your integration recipes. An example of this could be a project stored in a different platform, or even a list of all your boards.

What is a Custom Field?

The benefit in using a custom field is that it allows you to create a reusable object for your integration recipes (i.e. you can use them in both your trigger and action blocks).

Custom fields are useful when you want to load configuration data from an external platform into your integration recipe for use. For example, you can load options for your app users to choose from when configuring the recipe (i.e. a list of Zendesk tickets or Slack channels).

It’s important to consider reusability when building custom fields. This can help you in building out multiple integration recipes in your app, all using the same custom fields you define.

Custom Field Type Editor Configuration

To create a new custom field, click into the “Custom Blocks” tab of your app custom integration recipe:

custom blockscustom blocks

From there, you can click “Create new,” then “Field Type” to start building your custom field.

The “Name” of your custom field should describe what your custom field is (i.e. “Zendesk Ticket Fields,” or “ Boards List.” Adding a short “Description” will also help explain what your custom field contains.

Set a “Default field key” that will act as the name of this custom field type when you use it in your integration recipes.

The automation configuration of your custom field can be one of three options.

Text Field Type

The ”Text” type allows you to create a field type with a predefined field key for repeated use (for example, if you have a project with the field key “projectId,” you can utilize this key for all other trigger and action blocks instead of re-configuring it each time).

Text columns allow you to select whether your text custom field type has numbers only. This will force users to only add numeric characters, which can be useful if the custom field will only include numerals, like ID numbers.

List Field Type

The ”List” type allows you to generate an array of options for selection (for example, if you want to pull up a list of all the Zendesk tickets in an account).

If you want to manually define only a few field options, you can type different key-value pair “Options” in your list field type.

Alternatively, if you only want to load all of the list options remotely, you can populate the “Remote Options URL” with an endpoint URL that will contain all the array of values in your list.

custom field URLcustom field URL

You can also add “Dependencies” to the list field type that determine what other object this list field type is dependent on. For example, if I want to load all of the items on a specific board, the list field type of the item custom field will include a dependency of the board custom field.

If you choose to utilize a dependency, the payload to your remote options URL will look like this:

    "payload": {
        "boardId": 12345678, 
        "automationId": 123456, 
        "dependencyData": {
             "boardId": 12345678 
        "recipeId": 123456, //unique ID of the recipe in your app. the same recipe ID will be sent if two different accounts are using the same recipe
        "integrationId": 123456 //unique ID of the integration recipe on your board

In the above example, the dependent custom field URL payload will contain the ID of the custom field it's dependent on (i.e. the POST request for the remote options URL that loads a list of items will contain the board Id on which the items are located).

Dynamic Mapping Field Type

The ”Dynamic Mapping” type will allow you to define a custom object that contains a set of subfields. This is useful if you want to load data from a third-party software (for example mapping Zendesk ticket information into columns on a board).

The “Field Definitions URL” will load a payload of data that contains all of the fields for your custom field. This can be useful when you want to map data between and a different software.



Check out our Item Mapping and Custom Entities article for more information on how this custom field works.

Input and Output Fields

Each integration recipe has a “Trigger” and an “Action” block. The trigger block determines what initiates (or sets off) your integration recipe -- for example “When a Status changes”. The action block determines the action that you’re hoping to accomplish (for example “create a new item”).

Input and output fields are how the user passes configuration to a trigger/action block, and how data is transferred between blocks. For example, a user’s recipe configuration can be one of the input fields in your blocks, and the output fields of a trigger can be mapped to the input fields of the action.

Trigger I/O Fields

When building your own custom trigger, you can configure the input and output fields yourself.

The input fields of the trigger can come from either the context of your integration recipe, or from your recipe sentence (i.e. what the user chooses when using your integration recipe).

The output fields of your trigger are what will be mapped into your action’s input fields. If you’re using a built-in trigger, you can learn more about that trigger’s output fields by hovering your mouse over the toolkit information icon.

If you’re using a custom trigger, you can configure the output fields yourself. The output fields should contain the data you will be needing to utilize in your action block.



Feel free to check out our Custom Triggers article for specifics on setting this up.

For example, let’s say you’re looking to create a item each time you receive a ticket in Zendesk, the output fields of your trigger (which is “When a new ticket is submitted in Zendesk,”) will need to include the board Id of your board where this recipe sits so that your new item can be created in this board.

Action I/O Fields

Your action block will include only the ability to customize input fields, not output fields. This is because the output of this block is the action itself.



Feel free to check out our Custom Actions article for specifics on setting this up.

The input fields for your trigger will need to include all of the data needed to complete your action.

If you’re planning on using dynamic mapping into a item, the input field of your mapped item will need to be the output field of your trigger block and not the custom entity you’ve created. This is because the monday apps framework will do all of the mapping for you!

Remote Options Dependencies

In the example above, the “parent” custom field is the custom list of boards within a account. The dependent “child” custom field is the list of items on the selected board.

When setting up the custom action in your integration recipe that will utilize these remote options dependencies, the input field settings for the “child” (or the dependent custom field) will include a dependency on the “parent” custom field.

The input field in your custom action configuration for the “parent” remote list of boards would be as follows:


The input field in your custom action configuration for the “child” remote list of items would be as follows:


Congratulations Builder!

You now know the ins and outs of how data is transferred to, and between, the blocks in your integration recipes.

As a next step, check out the following resources:

Did this page help you?