Lookup Tables in Zapier: Formatter, Code Steps, Storage, and Zapier Tables

A practical field guide from Automation Ace.

Lookup Tables in Zapier: Formatter, Code Steps, Storage, and Zapier Tables

A lookup table maps an input value to a corresponding output value: state code → full state name, product SKU → price tier, country → currency, rep name → email address. In Zapier, you need this frequently — trigger data comes in one format, downstream apps expect another. There are four practical ways to implement lookup tables, each with different tradeoffs between simplicity, flexibility, and maintainability.

Short answer: use the Formatter Lookup Table for small, static one-to-one swaps; a Code step object map for multi-property mappings you maintain yourself; Zapier Storage for JSON data managed by code; and Zapier Tables when the lookup data changes often, has several columns, is shared across Zaps, or should be edited by non-technical teammates in a table instead of inside a Zap.

Option 1: Formatter Lookup Table Transform (No Code, Static Maps)

The Formatter by Zapier step includes a Lookup Table transform under the Utilities event. It's the no-code option for simple value-to-value mappings.

Setup

1. Add a Formatter by Zapier → Utilities → Lookup Table step
2. Set Lookup Key to the field whose value you want to map (e.g., State Code from the trigger)
3. In the lookup table rows, add key-value pairs: CA → California, TX → Texas, NY → New York, etc.
4. Set a Fallback Value for keys that don't match any row (e.g., Unknown)

The step's output is a single Output field containing the matched value, or the fallback. Map it to any downstream field.

Best For

• Simple one-to-one value conversions (code → label, abbreviation → full name)
• Small tables (under ~20 rows) that rarely change
• Zaps built by non-technical users who won't maintain code

Limitation: each Formatter Lookup Table step produces one output. For multi-property lookups (state code → full name + timezone + region), you need multiple Formatter steps or a Code step.

Option 2: JavaScript Object Map in a Code Step (Multi-Property, Static)

For lookups that return multiple values per key, or for tables with more than ~10 entries, a Code step with a plain JavaScript object is more efficient and easier to maintain than chaining multiple Formatter steps.

// Map product SKU to pricing tier, label, and support level
const skuMap = {
  'PRO-001':  { tier: 'enterprise', label: 'Enterprise Plan',  support: 'dedicated' },
  'PRO-002':  { tier: 'business',   label: 'Business Plan',    support: 'priority' },
  'PRO-003':  { tier: 'starter',    label: 'Starter Plan',     support: 'standard' },
  'FREE-001': { tier: 'free',       label: 'Free Plan',        support: 'community' }
};

const sku = inputData.sku;
const match = skuMap[sku] || { tier: 'unknown', label: 'Unknown SKU', support: 'none' };

output = {
  tier:    match.tier,
  label:   match.label,
  support: match.support,
  sku
};

Territory / Routing Lookup

// Map US state to sales rep email and region
const territoryMap = {
  'CA': { rep: 'sarah@company.com', region: 'West' },
  'OR': { rep: 'sarah@company.com', region: 'West' },
  'WA': { rep: 'sarah@company.com', region: 'West' },
  'TX': { rep: 'mike@company.com',  region: 'South' },
  'FL': { rep: 'mike@company.com',  region: 'South' },
  'NY': { rep: 'jane@company.com',  region: 'East' },
  'MA': { rep: 'jane@company.com',  region: 'East' }
};

const state = (inputData.state || '').toUpperCase().trim();
const territory = territoryMap[state] || { rep: 'general@company.com', region: 'Unassigned' };

output = {
  rep_email: territory.rep,
  region:    territory.region,
  state
};

Best For

• Multi-property returns per key
• Medium-sized tables (20–200 entries)
• Lookup logic maintained by someone comfortable editing code
• Case-insensitive matching (normalize with .toLowerCase() before the lookup)

Option 3: Zapier Storage for Dynamic Lookup Data

When the lookup table values change frequently — assignee lists, pricing tiers, territory maps updated by non-technical staff — hardcoding them in a Code step means editing the Zap every time. Zapier Storage lets you store the table as a JSON string and update it without touching the Zap.

Store the Lookup Table

Store the table in Zapier Storage as a JSON-serialized object. You can write it once via a setup Zap or directly via the Storage API:

// Write the lookup table to Zapier Storage (run once to initialize)
const storageSecret = inputData.storage_secret;
const lookupTable = {
  'CA': 'sarah@company.com',
  'TX': 'mike@company.com',
  'NY': 'jane@company.com'
};

await fetch('https://store.zapier.com/api/records', {
  method: 'POST',
  headers: { 'X-Secret': storageSecret },
  body: JSON.stringify({ territory_map: JSON.stringify(lookupTable) })
});

Read and Use the Lookup Table at Run Time

const storageSecret = inputData.storage_secret;

// Read the stored lookup table
const resp = await fetch(`https://store.zapier.com/api/records?secret=${storageSecret}`);
const stored = await resp.json();

let territoryMap = {};
try {
  territoryMap = JSON.parse(stored.territory_map || '{}');
} catch (e) {
  territoryMap = {};
}

const state = (inputData.state || '').toUpperCase();
const repEmail = territoryMap[state] || 'general@company.com';

output = { rep_email: repEmail, state };

For Zapier Storage setup and patterns, see the Zapier Storage API guide.

Best For

• Lookup data updated by operations or non-technical staff without Zap edits
• Large tables that would be unwieldy in a Code step
• Shared tables used by multiple Zaps (one Storage key, many Zaps read from it)

Option 4: Zapier Tables for Editable, Multi-Column Lookups (No Code, Dynamic)

Zapier Tables is Zapier's built-in database. It stores rows and columns you can view and edit in a spreadsheet-style table, and it plugs directly into Zaps. For lookups, that combines the best parts of the other options: no code like Formatter, multiple return values like a Code step, and data that changes without editing the Zap like Storage, but in a table anyone on your team can read and update.

Build the Lookup Table

1. Create a table, for example Territory Map, with a key column (State) and one column per value you need (Rep Email, Region, Timezone).
2. Add one row per key: CA | sarah@company.com | West | America/Los_Angeles.
3. Keep keys unique and normalized, such as uppercase two-letter codes, so matches are reliable.
4. Optionally add a Default row to hold fallback values, and a Notes or Updated By column for auditability.

You can type rows in, paste them, or import a CSV. Teammates can then maintain the table directly, or through a Zapier Interfaces form if you want tighter control. See Zapier Interfaces for internal tools.

Look Up Values in a Zap

1. Add a Zapier Tables → Find Record step after your trigger.
2. Choose the table, set the lookup field to the key column (State), and map the incoming value, normalized first if needed with Formatter.
3. Map the returned columns (Rep Email, Region, Timezone) into any later step.
4. Handle misses: add a Filter or Paths on whether the search found a record, fall back to your Default row, or use Find or Create Record when a miss should add a new row for someone to fill in.

Trigger: new lead (state = "tx")
  → Formatter: uppercase + trim → "TX"
  → Zapier Tables: Find Record in "Territory Map" where State = "TX"
      → Rep Email: mike@company.com, Region: South, Timezone: America/Chicago
  → CRM: assign owner = Rep Email
  → Slack: notify #sales-south

Beyond Lookups: Why Tables Often Wins for Teams

• One table, many Zaps. Routing, pricing, and assignment Zaps can all read the same table, so an update applies everywhere at once.
• Visible and auditable. Non-technical owners can see exactly what the automation will do, unlike values hidden inside a Code step.
• Triggers and actions. Zapier Tables can also start Zaps when records are added, updated, or deleted, or when someone clicks a button field, and Zaps can create, update, and delete records. That makes it useful for Zap run logs, sequential queues, and deduplication keys.
• Task-friendly. Zapier states that Tables steps in Zaps do not count toward task usage, which makes frequent lookups inexpensive. See Zapier apps that don't use tasks.

Limits and Considerations

• Plan limits: the number of tables, records per table, and fields depend on your Zapier plan. Check Zapier's Tables usage limits before loading large reference data.
• Rate limits: very high-volume Zaps hitting the same table can run into Tables rate limits.
• Exact matching: searches match the value you send, so normalize case and whitespace first. See why a mapped field is blank.
• Not a full database: for complex relational data, reporting, or interfaces used across the business, compare options in Zapier Tables vs Airtable vs Google Sheets and Airtable automation.

Best For

• Lookup data owned by operations, sales, or finance teams who should not edit Zaps
• Multi-column lookups (one key returns several values) without code
• Reference data shared by several Zaps
• Tables that change weekly or monthly, such as territories, price lists, owner assignments, or SLA rules

For more on when Tables beats Storage in general, see Storage by Zapier vs Zapier Tables.

Choosing the Right Approach

Pick Formatter for simple value swaps, a Code step object for multi-property mappings you own, Zapier Storage when a script manages the data, and Zapier Tables when the table is maintained by someone who shouldn't need to edit the Zap. The Code step object map is the most versatile — it's fast, readable, handles fallbacks cleanly, and can be extended to return multiple properties per lookup key in a single step.

For the Code step patterns used in the object map approach, see if/else and switch statements in Zapier Code steps. For storing and retrieving dynamic data with Zapier Storage, see the Zapier Storage API guide. For setting fallback default values when a lookup returns nothing, see default values with Zapier Formatter. For choosing between Zapier Tables and other data stores, see Zapier Tables vs Airtable vs Google Sheets. For a real routing example, see lead routing automation. For help designing a routing or value-mapping workflow, talk to Automation Ace.

Frequently Asked Questions

What is a lookup table in Zapier?

A lookup table maps an input value to an output value, such as a state code to a sales rep email or a SKU to a pricing tier. In Zapier you can build one with Formatter, a Code step, Zapier Storage, or Zapier Tables.

How do I use Zapier Tables as a lookup table?

Store one row per key in a Zapier Table, then add a Zapier Tables Find Record step that searches the key column for the incoming value. Map the returned fields into later steps, and handle the not-found case with a fallback.

Should I use Formatter Lookup Table or Zapier Tables?

Use the Formatter Lookup Table for small, static, one-to-one mappings that rarely change. Use Zapier Tables when the table has several columns, changes often, is shared by multiple Zaps, or needs to be edited by someone who should not edit Zaps.

Do Zapier Tables steps use tasks?

Zapier states that Tables steps in Zaps do not count toward task usage. Table and record limits depend on your plan, so check Zapier's Tables usage limits.

What happens if a lookup value is not found?

Set a fallback. Formatter has a Fallback Value field, Code steps can use a default object, and Zapier Tables searches can be followed by a Filter or Paths on whether the search found a record, or replaced with Find or Create Record.