How to Work with Item Data Types in Make.com

What item data types mean in Make.com

An item is an individual value carried by a Make.com module. Its data type describes how that value should be interpreted and what operations are appropriate. A bundle is the larger group of named items produced or received during one module operation.

For example, a customer bundle might contain a Text name, a Text email address, a Boolean indicating consent, a Date for the last contact, and an Array of associated orders. Those values may belong to the same business record, but they do not have the same structure or behavior.

• Text: characters, words, identifiers, URLs, or formatted content.
• Number: numeric values used for calculations, quantities, scores, or amounts.
• Boolean: a true or false value used for logical decisions.
• Date: a date or time value used for scheduling and comparison.
• Array: an ordered list of values or collections.
• Object: a structured value containing named properties.
• File: file content and related file information.
• Unsupported: a value Make.com cannot represent or process as a normal supported type.

How bundles and module handoffs work

Modules generally receive input, perform an operation, and produce one or more output bundles. Each bundle contains fields that downstream modules can map. A downstream field may accept only a particular structure, even when the mapped value appears visually similar.

Consider a quantity stored as the text value “12”. It may display correctly in a message, but a calculation or numeric comparison requires it to behave as a Number. Similarly, an order containing several line items is not one text field simply because it is displayed in one output panel. It is usually a collection that needs to be iterated, aggregated, or mapped as a structured value.

When debugging, inspect the output bundle from the module that creates the value rather than starting with the final error. Ask three questions:

1. What type did the source module actually produce?
2. What type or structure does the destination field expect?
3. Does the value represent one business item or a collection of items?

This distinction is useful beyond Make.com. A scenario is easier to maintain when every handoff has a clear input shape, an accountable owner, and a defined result.

The core Make.com item data types

Text

Text is a sequence of characters. Names, email addresses, product codes, URLs, descriptions, and many external IDs are commonly represented as Text. A value containing digits is not automatically a Number. An invoice reference such as “00127” should normally remain text because removing leading zeros could change its meaning.

Text can also contain JSON, HTML, or a date-like string. Its content may look structured without being available as structured data. If a later module needs individual properties from that content, parse or transform it before mapping those properties.

Number

Number represents numeric values, including integers and decimal values. Use it when the scenario needs arithmetic, numeric comparison, quantity handling, or a value that a destination application explicitly defines as numeric.

Do not assume every price, score, or ID should be a Number. A product code such as 00042 is an identifier, not a quantity. Decide based on business meaning first, then convert only when the destination operation requires numeric behavior. Also check how decimal separators, empty values, and currency formatting are handled before using a value in a calculation.

Boolean

Boolean has two logical states: true and false. It is useful for filters, routing conditions, feature flags, completion indicators, and consent states.

Text values such as “yes”, “no”, “true”, or “false” are not necessarily Boolean values. A scenario should define how source values are interpreted, especially when a source system uses blanks, numbers, or custom labels. A blank value may mean unknown rather than false, and collapsing those states can create incorrect decisions.

Date

Date represents a point in time or a date-time value. Dates are used for scheduling, ageing records, comparing deadlines, and recording when a business event occurred.

Use date functions for adding intervals, comparing values, or formatting a date for a destination system. Keep the underlying business meaning clear. A date can represent when an item was created, when it is due, or when it was last processed. Those are different fields even if they use the same technical type.

Time zones and formatting should be considered at system boundaries. Store or pass a consistent value where possible, and format it for display only when a receiving application or human reader needs a particular presentation.

Array

An Array is an ordered list of values. Line items, tags, recipients, search results, and related records are common examples. The items inside an array may themselves be Text, Number, Boolean, or Object values.

An array should not be mapped as though it were one ordinary record. If the business action must happen once per element, use an Iterator pattern. If several bundles need to become one list for a later step, use an Aggregator pattern where appropriate. The correct choice depends on whether the scenario is splitting one collection into separate actions or combining multiple results into one output.

Object

An Object is a structured value made up of named properties. A contact object might contain a name, email, phone number, and address object. Each property can have its own type, and objects can be nested inside arrays or other objects.

When mapping an object, identify the exact property required by the destination. Passing a whole object into a field that expects a single Text value creates ambiguity and may produce an invalid request. For webhook and JSON-based integrations, inspect the complete structure rather than relying only on the field label shown in the mapping interface.

File

File represents file content together with information needed to handle it, such as a name or content type. PDFs, images, spreadsheets, and documents should be passed to fields that expect files or file-related input.

A file reference, a download URL, and the file content are not always interchangeable. Before mapping a file, confirm whether the next module expects an actual file object, a URL, or a text name. File handling also depends on the limits and accepted formats of the receiving application, so validate the handoff with a representative test file.

Unsupported data

Unsupported data indicates that Make.com cannot work with the value as a normal recognized type. It may result from an unusual source structure, an application-specific value, or a field that has not been exposed in a usable form.

Do not build critical logic around an unsupported value without first understanding its source. Review the originating module, simplify the payload if possible, or convert the value into a supported representation. If the original system can return a clearer field, that is usually preferable to adding complicated repair logic later.

A practical sequence for reliable mapping

Use the following sequence when creating or repairing a scenario. It separates data inspection from business decisions and keeps conversions close to the relevant handoff.

This sequence prevents a common mistake: choosing a function before deciding what the field is supposed to mean. A function can change a value’s representation, but it cannot resolve unclear ownership, missing business rules, or an incorrectly designed workflow.

Common data type failures and how to diagnose them

A number is treated as text

If a numeric comparison or calculation behaves incorrectly, inspect whether the source value includes currency symbols, separators, whitespace, or other characters. Remove presentation formatting before converting it, and decide how blanks should behave. Do not silently turn an invalid amount into zero unless that is the intended business rule.

A text flag is used as a Boolean

Source systems often store status values as labels rather than logical values. Map each accepted source state to an explicit Boolean result, and decide what should happen when the source is blank or unfamiliar. This creates a visible rule instead of relying on implicit interpretation.

An array is mapped into a single field

When only one item appears in the output, the scenario may be using the first element unintentionally. Ask whether the destination should receive one selected value, a joined text list, or one action per array element. That is a workflow decision, not just a formatting decision.

An object is passed where one property is needed

Open the object and map the specific property required by the destination. If the destination needs a new structured payload, build that payload deliberately and document its expected shape through the module configuration or scenario notes.

A date is correct technically but wrong operationally

Check whether the date represents the right event and whether the time zone matches the business process. A correctly formatted created date is still the wrong input if the workflow is meant to act on a due date.

Designing scenarios that remain understandable

Correct types reduce technical errors, but reliable automation also depends on clear process design. A field should have an owner, a purpose, and a known meaning. If different teams use the same status field to mean different things, perfect type conversion will not fix the workflow.

Keep conversion logic near the source or destination boundary where it is needed. Avoid converting the same field repeatedly across a long chain of modules. If a scenario needs many repeated transformations, consider whether the source data model, intermediate object, or receiving application should be redesigned.

It is also useful to name and document meaningful business states. For example, a Boolean can indicate whether an item is approved, while a Text status can explain whether it is new, under review, or rejected. These are related but not interchangeable. Reporting and routing become clearer when each field answers one question.

For wider automation and systems work, ConsultEvo’s systems and automation services take the same process-first approach: clarify the operating model before adding tools or automation. In data-heavy environments, a connected operating platform also depends on clean structures and reliable handoffs, as shown by this ConsultEvoCommerce and Operations Intelligence PlatformAn example of connected operational data, reporting, and system access.→

The best Make.com scenarios are not the ones with the most functions. They are the ones where each module receives the right shape of data, each conversion has a reason, and each output supports a clear next decision.