Uso de armazenamentos de dados para estado persistente

By default, each run of a workflow starts fresh and remembers nothing from the last run. That makes some tasks tricky: how do you avoid processing the same record twice, or keep a running total?

You need a way to persist state between runs.

A data store is a simple built-in database provided by the automation platform. You define a structure of fields, and your workflow can save, read, update, and delete records in it.

It lives inside the platform, so there is no separate spreadsheet or server to manage.

You could use Google Sheets to store state, but a data store is purpose-built:

• Faster lookups by a unique key
• No row limits or formatting quirks
• Designed for automation read and write

For internal workflow state, a data store is usually the cleaner choice.

When you create a data store, you define its fields and their types — text, number, date, boolean. You also pick a key, a unique identifier for each record, such as an email or an order ID.

The key is how you find a specific record later.

An add or set operation writes a new record into the store. You map workflow data into each field, and the platform saves it under its key.

If a record with that key already exists, you can choose to overwrite or skip it.

A get operation retrieves a record by its key. The returned fields become available to later steps, just like any other data.

This lets a workflow recall what it knew about an item from a previous run.

A classic use is preventing duplicates. Before processing an item, check the store for its key. If a record exists, skip it; if not, process the item and add a record.

This guarantees each item is handled exactly once across all runs.

Data stores can hold numbers you increment over time. Read the current value, add to it, then write it back.

This is how a workflow keeps a daily counter, a running sum, or a sequence number that survives between runs.

Beyond adding, you can update fields on an existing record or delete records you no longer need.

Regular cleanup keeps the store small and fast, especially for high-volume workflows.

Data stores are lightweight, not full databases. Watch for:

• Storage size limits on your plan
• No complex queries or joins like SQL
• Best for keys-and-values, not relational data

For heavy relational needs, an external database is still the right tool.

Reach for a data store when you need to remember small amounts of state: which items were processed, a configuration value, a counter, or a temporary mapping.

It bridges the gap between stateless runs and a full database.

Test your understanding of data stores.

You learned to use data stores for persistent state:

• Data stores remember information between workflow runs
• Define fields and a unique key, then add, get, update, and delete records
• Use them for deduplication, counters, and running totals
• They are lightweight, not a replacement for a full relational database

Persistent state unlocks smarter, stateful automations.