In the previous article, you learned what data is, why it matters, and how to think about the different categories of data you will encounter as an automation builder. Now it is time to go one level deeper and examine the specific data types that will show up in virtually every workflow you build.

This is where theory meets practice. When data moves through an automation platform, it does not travel as a vague blob of information. It moves in a structured format, and every individual piece of data within that structure has a specific type. A customer’s name is a string. Their age is a number. Whether they have opted into your mailing list is a boolean. The list of products they purchased is an array. And the complete record of their profile information is an object.

Understanding these data types is not just academic knowledge — it is one of the most practical skills you will use as an automation builder. Errors in workflows frequently come down to data type mismatches: your system expected a number but received a string, or it was looking for an object but got a null value instead. These are the kinds of problems that stop workflows dead in their tracks, and they are almost always avoidable when you understand what each data type is, how it behaves, and how to work with it.

In this article, you will learn the six core data types you will encounter in automation platforms, understand how they are represented in JSON — the universal format for data exchange in modern automation — and gain the practical knowledge you need to inspect, manage, and troubleshoot data as it flows through your systems.

How Data Travels Through Your Workflows

Before diving into the individual data types, it helps to understand the format that carries them. In most modern automation platforms, data flows through your workflows in a format called JSON, which stands for JavaScript Object Notation. Do not let the name intimidate you — JSON is one of the simplest and most readable data formats in existence, and you will become very comfortable with it through practice.

JSON organizes information using a concept called key-value pairs. If you are familiar with spreadsheets, you can think of keys as the column headers and values as the data in each cell. For example, in a spreadsheet, you might have a column labeled “customer_name” and a row value of “Maria Santos.” In JSON, that same information would be expressed as a pair: the key is “customer_name” and the value is “Maria Santos.”

Every piece of data flowing through your automation is organized this way. Each node in your workflow receives input data as a collection of key-value pairs, processes it according to your logic, and then passes output data — also as key-value pairs — to the next node in the chain. What makes this system work is that every value has a specific data type, and the automation platform uses that type to determine how to handle, display, and process that particular piece of data.

Most automation platforms give you multiple ways to view this data as it passes through your workflow. You can typically see it in a table format that resembles a spreadsheet, a raw JSON view that shows you the exact structure and syntax, or a schema view that presents the data in a collapsible, hierarchical tree. Each view has its strengths, and learning to switch between them depending on what you are inspecting is a skill that will serve you well as your workflows become more complex.

Strings: The Language of Text

The most common data type you will encounter in your automations is the string. A string is simply text — any sequence of characters, whether it is a single word, a phrase, a full sentence, or even an entire paragraph. Names, email addresses, physical addresses, product descriptions, chat messages, URLs, and any other piece of information expressed in words or characters are stored as a string.

In JSON, strings are always enclosed in quotation marks. This is how the system distinguishes text from other data types. For instance, if your workflow is processing customer data, you might see a key-value pair where the key is “full_name,” and the value is “David Kim” — with quotation marks around both the key and the value. Those quotation marks tell the system that this is text, not a number, not a true/false value, and not any other data type.

This distinction matters more than you might expect. Consider a scenario where your workflow processes order numbers. An order number like “ORD-4829” is clearly text because it contains letters and a hyphen. But what about a numeric order ID like 4829? If that ID is stored as a string — “4829” with quotation marks — the system treats it as text. If it is stored as a number — 4829 without quotation marks — the system treats it as a numerical value. The two are not interchangeable, and trying to perform mathematical calculations on a string or text comparisons on a number will cause errors in your workflow.

Strings are the workhorses of most automations. Whenever your system reads an email body, processes a form submission, generates AI-written content, or sends a notification message, it is working with strings. Getting comfortable with how strings behave — and how they differ from other data types — is one of the first practical skills you will develop.

Numbers: Integers and Floats

The next data type is the number, and it comes in two varieties that are worth understanding: integers and floats.

An integer is a whole number with no decimal point. Think of quantities like the number of items in a shopping cart, the number of employees in a department, or a customer’s age. These are all integers — clean, whole values like 5, 42, or 1000.

A float — short for floating-point number — is a number that includes a decimal. Prices, percentages, ratings, and measurements are common examples. A product price of 29.99, a customer satisfaction rating of 4.7, or a temperature reading of 68.5 are all floats.

In most automation platforms, both integers and floats are simply categorized under the umbrella of “number,” and the system handles the distinction automatically. But it is useful to be aware of the difference because it can matter in certain contexts. For example, if your workflow calculates the number of units to order from a supplier, you want that result to be a whole number — you cannot order 12.6 units of a product. If your workflow calculates an average customer spending amount, the result will naturally be a float with decimal places.

In JSON, numbers appear without quotation marks. This is the key visual difference between a number and a string that happens to contain digits. The value 30 without quotes is a number. The value “30” with quotes is a string. Your automation platform treats these two very differently, and confusing them is one of the most common sources of workflow errors. If you ever encounter an error message suggesting that the system received a string when it expected a number — or vice versa — this is almost certainly the issue.

Booleans: The Yes-or-No Decision Makers

A boolean is the simplest of all data types. It can hold exactly two possible values: true or false. There is no middle ground, no nuance, no range of options — just a binary choice.

Booleans are used to represent any piece of information that naturally falls into a yes-or-no category. Is this customer account active? True or false. Has this subscriber confirmed their email address? True or false. Is this order eligible for free shipping? True or false. Does this lead meet the qualification criteria? True or false.

In JSON, boolean values appear as the words true or false, written in lowercase and without quotation marks. This last detail is important and catches many beginners off guard. The value true without quotes is a boolean. The value “true” with quotes is a string — it is just the word “true” stored as text, not as a logical true/false value. Your automation platform will interpret these very differently, especially when using them in conditional logic.

Booleans are particularly powerful when you are building decision points in your workflows. Most automation platforms include conditional nodes — sometimes called “if” nodes or “filter” nodes — that evaluate a condition and route data down different paths based on the result. Boolean values are tailor-made for this purpose. If a customer’s “is_subscribed” field is true, send them the newsletter. If it is false, send them a subscription invitation instead. This kind of branching logic is at the heart of most automations, and booleans make it clean and reliable.

Arrays: Ordered Lists of Values

An array is an ordered list of values. It is a single data type that contains multiple items within it, and those items can be of any data type — strings, numbers, booleans, or even other arrays and objects.

Think of an array as a container that holds a collection of related items in a specific order. A customer’s list of purchased product categories might be stored as an array containing the values “electronics,” “books,” and “home goods.” A list of tags associated with a blog post might be an array of strings. A sequence of test scores might be an array of numbers.

In JSON, arrays are enclosed in square brackets, with each item separated by a comma. For example, a key called “interests” might have an array value that looks like this: [“photography”, “hiking”, “cooking”]. The square brackets tell the system that this is a list, and the items within it are the individual elements of that list.

One important detail about arrays is that each item within them has a position number, called an index, and that numbering starts at zero rather than one. So in the array [“photography”, “hiking”, “cooking”], “photography” is at index 0, “hiking” is at index 1, and “cooking” is at index 2. This zero-based indexing is a universal convention in programming and data systems, and you will encounter it frequently when you need to reference or extract specific items from an array.

Arrays are especially valuable in automations that involve looping. If you have an array of fifteen email addresses, you can build a workflow that loops through each item in the array and performs an action for each one — sending a personalized message, looking up a profile, or updating a record. This ability to iterate through lists is one of the most powerful capabilities in automation, and it relies entirely on the array data type.

Objects: Structured Collections of Key-Value Pairs

Objects are where things start to get more interesting — and occasionally more confusing. An object is a collection of key-value pairs grouped together under a single label. It is essentially a container that holds multiple named pieces of data about a single entity.

For example, imagine your workflow processes contact form submissions. Each submission might arrive as an object called “contact” that contains several key-value pairs inside it: a key called “first_name” with a value of “Priya,” a key called “last_name” with a value of “Patel,” a key called “email” with a value of “priya@example.com,” and a key called “company_id” with a value of 2045. Notice that within this single object, you have a mix of data types — strings for the name and email, and a number for the company ID. Objects can contain any combination of data types as their values.

In JSON, objects are enclosed in curly braces. The entire collection of key-value pairs sits between an opening curly brace and a closing curly brace, which tells the system that all of these pairs belong together as one structured unit.

Objects and arrays are sometimes confused because they can look similar at first glance — both are containers that hold multiple pieces of data. The key difference is that arrays are ordered lists where each item is identified by its position number (index 0, index 1, index 2), while objects are collections where each item is identified by its key name (“first_name,” “email,” “company_id”). In an array, the items are just values lined up in sequence. In an object, every value has a descriptive label attached to it.

Objects are the fundamental building blocks of structured data in automation workflows. When a webhook delivers a form submission, it typically arrives as an object. When an API returns information about a customer, that information comes packaged as an object. When your workflow builds a record to send to a CRM or a database, you are constructing an object. Understanding how objects work — how to read them, how to access individual values within them, and how they nest inside each other — is essential for working effectively with automation platforms.

Null: The Absence of Data

The final core data type is null, and it represents something very specific: the complete absence of a value. Null does not mean zero. It does not mean an empty piece of text. It means that no data exists at all for that particular field.

This distinction is subtle but critically important for your automation logic. Consider a field called “phone_number” in a customer record. There are three very different states this field could be in. First, it could contain an actual phone number like “+1-555-0123” — that is a string with real data. Second, it could be an empty string — the field exists, but no value was entered. Third, it could be null — the field has no value whatsoever, not even an empty one.

In JSON, null appears as the word null, written in lowercase and without quotation marks. This makes it visually distinct from a string (which has quotes), a number (which is a digit), a boolean (which is true or false), and an empty string (which appears as two quotation marks with nothing between them).

Why does this matter for your workflows? Because many automation operations depend on checking whether data exists. If you build a workflow that filters out records where no phone number was provided, you need to know whether you are checking for null values, empty strings, or both — because the system treats them differently. A field with a null value typically means the data was never provided or does not exist in the source system. A field with an empty string means the field exists and was acknowledged, but no content was entered. Both might indicate a missing phone number in a practical sense, but your automation logic may need to handle each case separately.

The Zero vs. Null Distinction

There is another related distinction that trips up even experienced automation builders: the difference between zero and null in numerical contexts.

Imagine a field called “daily_sales” in a business dashboard. If the value is 0, that communicates a clear piece of information: the business made zero sales today. It is a real data point with a real meaning. But if the value is null, it means something entirely different: the sales data for today has not been recorded yet, or the data source was unavailable, or the field simply does not apply. Zero is a measurement. Null is the absence of a measurement.

In your automations, this distinction can have significant consequences. A workflow that calculates average daily sales would handle these two cases very differently. A zero should be included in the average calculation because it represents a real data point. A null should probably be excluded because there is no data to average. Getting this wrong can lead to inaccurate calculations, misleading reports, and flawed decision-making downstream.

The practical lesson is straightforward: whenever you are working with data in your automations, be mindful of the difference between a field that contains a zero or empty value and a field that is null. They look similar on the surface, but they carry very different meanings, and your workflow logic should account for both.

How Data Types Shape Your Workflow Logic

Now that you understand each of the six core data types, it is worth stepping back to see how they work together in the context of real automation workflows. Each data type lends itself to specific kinds of operations, and recognizing these patterns will help you design smarter, more efficient systems.

Booleans are your go-to data type for decision points. Whenever your workflow needs to evaluate a condition and route data down different paths — send this customer to the VIP track or the standard track, flag this support ticket as urgent or routine, approve this expense, or escalate it for review — boolean values make that logic clean and reliable.

Arrays are essential for any workflow that involves repetition or bulk processing. If you need to send a personalized email to every contact in a list, research each topic in a collection of subjects, or process every line item in an invoice, you will be working with arrays and the looping mechanisms that iterate through them one item at a time.

Numbers drive calculations. Whether you are computing totals, applying discounts, calculating averages, converting currencies, or evaluating thresholds — any time your workflow needs to do math, it is working with numerical data types. Ensuring that your numerical data is actually stored as numbers (and not as strings that happen to contain digits) is essential for these operations to work correctly.

Objects provide the structure for complex, multi-attribute data. Whenever your workflow handles entities with multiple properties — a customer with a name, email, plan type, and account status; a product with a title, price, description, and inventory count — those entities are represented as objects. Understanding how to navigate the key-value pairs within objects and how to extract specific values from nested structures is one of the most important practical skills in automation building.

And strings, the most ubiquitous data type of all, are present in nearly every operation — from reading input text and generating AI responses to constructing messages and populating fields in external systems.

Practical Tips for Working with Data Types

As you start building and testing your workflows, here are several practical habits that will save you hours of troubleshooting and prevent many of the most common data-related errors.

First, always inspect your data at each stage of the workflow. Most automation platforms let you view the input and output of every node. Make it a habit to check what data is coming in, what type each value is, and what the output looks like after processing. This simple discipline catches problems early, before they cascade through the rest of your system.

Second, pay close attention to data type mismatches. If a node in your workflow expects to receive a number but instead receives a string containing a number — say, “42” instead of 42 — it may throw an error or produce unexpected behavior. When you encounter error messages that mention unexpected types or failed conversions, this is almost always the root cause. Most platforms provide tools to convert data from one type to another, and learning to use those conversion tools will become second nature.

Third, use the right comparison operators in your conditional logic. Comparing a string to a number, or checking whether a boolean equals the string “true” instead of the boolean value true, will produce incorrect results that can be difficult to diagnose. Always verify that the values on both sides of a comparison are the same data type.

Fourth, test your workflows with a variety of inputs, including edge cases. What happens when a field is null? What happens when an array is empty? What happens when a number field contains zero? What happens when a required string is blank? Testing these scenarios before deploying your automation helps you discover and handle unexpected situations gracefully rather than having your system fail silently in production.

Finally, use data transformation and formatting tools within your automation platform to clean and standardize your data early in the workflow. Converting types, trimming whitespace from strings, setting default values for null fields, and validating data formats at the point of entry prevent problems from propagating through the rest of your system. A few minutes spent on data hygiene at the beginning of a workflow can save you hours of debugging later.

Data types may seem like a small detail in the grand scheme of building automations, but they are the foundation upon which everything else depends. Every key-value pair flowing through your system carries a type, and that type determines what you can do with it, how it behaves in calculations and comparisons, and whether your workflow executes smoothly or breaks. Master these building blocks, and you will have the practical foundation to build workflows that are not just functional, but robust, reliable, and ready for the real world.