> For the complete documentation index, see [llms.txt](https://docs.getint.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.getint.io/getintio-platform/workflows/dynamic-fields.md). # Dynamic Fields ## Extend Your Integration with Custom Scripted Fields Dynamic Fields allow you to go beyond Getint's built-in field support and sync data that isn't natively available through the standard field mapping interface. Whether you need to surface a deeply nested API value, compute a derived field, or populate a dropdown from a live endpoint, Dynamic Fields give you the scripting flexibility to make it happen. The scripting language used is **ES5 (JavaScript)**. ### Supported Field Types When creating a Dynamic Field, you'll need to select one of the following types depending on the kind of data you're working with: * **String**: Plain text values (e.g., a summary or description excerpt). * **Number**: Numeric values (e.g., story points, counts). * **IdLabel**: A single selectable option with an ID and a display label (e.g., assignee, priority). * **IdLabelArray**: A multi-select list of IdLabel options (e.g., labels, components). * **Boolean**: True/false values. * **Date**: A date value without time. * **DateTime**: A date value with time. ### Understanding the Script Structure Every Dynamic Field script uses a `switch (mode)` block to handle two or three distinct operations: * `case 'value'`: Reads the field from the item returned by the source system's API. * `case 'set'`: Writes the value back to the source system when an update comes in from the other side. * `case 'options'`: *(IdLabel and IdLabelArray only)* Fetches the list of available options so they can be mapped in the integration settings. The `item` variable holds the full JSON payload received from the initial GET request to the source API. The `propertyValue` variable holds the incoming value from the mapped field on the other side of the integration. {% hint style="info" %} When a Dynamic Field is set to **read-only**, the `case 'set'` block is removed by default. {% endhint %} #### Example: String Field (Summary) This example reads and writes a plain text field — in this case, the `summary` field from a Jira issue. ``` switch (mode) { case 'value': if (item && item.fields && item.fields.summary) { dynamicField['String'] = item.fields.summary; } break; case 'set': if (propertyValue != null) { dynamicField['reqObject'] = { summary: propertyValue.value }; } break; } ``` #### How it Works: * `case 'value'`: Checks that the `item` object and its nested `fields.summary` property exists, then it assigns the value to `dynamicField['String']`. The `item` object represents the full API response, for example: ``` { "id": "378250", "key": "ASD-561", "fields": { "summary": "Explaining Dynamic Fields" } } ``` * `case 'set'`: When the mapped field is updated on the other side of the integration, `propertyValue` carries the new value. This case packages it into `reqObject` in the format the API expects, so it can be written back. #### Example: IdLabel Field (Assignee) `IdLabel` and `IdLabelArray` fields represent dropdown and multi-select options, respectively. They require an additional `case 'options'` block to fetch the available values from the source API so they can be mapped in Getint. ``` switch (mode) { case 'value': if (item && item.fields && item.fields.assignee) { dynamicField['IdLabel'] = { id: item.fields.assignee.accountId, label: item.fields.assignee.displayName }; } break; case 'set': if (propertyValue != null) { dynamicField['reqObject'] = { assignee: { accountId: propertyValue.id } }; } break; case 'options': var assignees = api.fetch('/rest/api/3/user/assignable/search?project=YOUR_PROJECT_KEY'); if (assignees) { dynamicField['options'] = assignees.map(function (assignee) { return { id: assignee.accountId, label: assignee.displayName }; }); } break; } ``` #### How it Works: * `case 'value'`: Reads the assignee's `accountId` as the `id` and `displayName` as the `label`, building the `IdLabel` object Getint expects. * `case 'set'`: Sends the `accountId` back to the API when an assignee is updated from the other side. * `case 'options'`: Calls the assignable users endpoint using `api.fetch()` and maps the results into `{ id, label }` pairs. These options will appear in the field mapping dropdown inside Getint. {% hint style="info" %} **Tip**: Replace `YOUR_PROJECT_KEY` with the actual project key you're working with. {% endhint %} #### Available API Utilities The following helper functions are available inside Dynamic Field scripts: | Function | Description | | ------------------------------------ | ---------------------------------------------------------------------------- | | `api.fetch('URL')` | Performs a GET request to the specified URL and returns the parsed response. | | `api.log("message")` | Prints a line to the sync logs — requires DEBUG log level to be enabled. | | `api.getRunCacheData('name')` | Retrieves a previously cached value for the current sync run. | | `api.setRunCacheData('name', value)` | Stores a value in cache for reuse during the same sync run. | **Making Write Requests**: If you need to POST, PUT, or PATCH data as part of your Dynamic Field logic, use the following, depending on which side the Dynamic Field is defined: *If the Dynamic Field is on the **right** side of the integration:* * `api.rightApp.post()` * `api.rightApp.put()` * `api.rightApp.patch()` *If the Dynamic Field is on the **left** side of the integration:* * `api.leftApp.post()` * `api.leftApp.put()` * `api.leftApp.patch()` #### Debugging Your Script Use `api.log()` statements to inspect values at runtime. This is especially useful when you're unsure how the source API formats a particular field. ``` case 'value': api.log(JSON.stringify(item.fields)); break; ``` Once you've confirmed the structure, you can remove the log statement and write the final field assignment. {% hint style="info" %} Debug-level logs must be enabled in your integration settings for the `api.log()` output to appear. {% endhint %} #### How to Create a Dynamic Field Follow the steps below to set up a Dynamic Field inside your integration. 1. **Open your integration** and navigate to your **issue type mappings**.
2. Go to the **Field Mappings** section for the relevant issue type and click the **Create Dynamic Field** button.
3. A panel will appear where you can: * Enter a **name** for the Dynamic Field. * Select the **field type** from the dropdown list (String, Number, IdLabel, IdLabelArray, Boolean, Date, or DateTime).
4. Once the type is selected, **add the corresponding script** to define how Getint should read and write the field. Refer to the examples above for the correct script structure based on your chosen type. When everything is configured, click **Create** to save the Dynamic Field.
5. The new field will now appear in the **available field mappings** list on the side of the integration where it was created, ready to be mapped to a field on the other side.
6. Once created, the Dynamic Field behaves like any standard field — it can be mapped freely and configured with a sync direction that fits your workflow.
{% hint style="warning" %} While the examples in this article use Jira to illustrate the concepts, Dynamic Fields work across **all connectors supported by Getint** — including ServiceNow, Salesforce, Azure DevOps, Monday.com, ClickUp, Asana, Zendesk, HubSpot, and more. The scripting principles, switch (mode) structure, and api utilities are the same regardless of which tools you are integrating. Always refer to the target system's API documentation to determine the correct field paths and request formats. {% endhint %} ### Important Notes Different systems return data in different formats — this is especially common with date fields and IdLabel-type fields. Always use api.log() to inspect the raw payload before writing your field assignment, and verify that the value you're passing matches the format expected by the receiving API. Caching with api.getRunCacheData() and api.setRunCacheData() is useful when your script needs to make the same API call multiple times in a single sync run. Store the result on the first call and retrieve it on subsequent ones to avoid redundant requests. ### Conclusion Dynamic Fields are a powerful tool for handling non-standard or deeply nested data that falls outside Getint's native field support. By combining `case 'value'`, `case 'set'`, and `case 'options'`, you can fully control how a field is read, written, and presented for mapping, giving you precise control over your integration logic. If you need assistance building a Dynamic Field script for your specific use case, don't hesitate to reach out through our [Support Portal](https://getint.io/help-center). Our team is happy to help.

Start your integration journey. Schedule a free consultation with our Getint Integration Expert today!

--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.getint.io/getintio-platform/workflows/dynamic-fields.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.