Lookup Table

A Lookup Table is a lightweight data store built directly into DecisionRules. Think of it as a spreadsheet that lives inside your workspace — you define rows and columns, fill it with data, and your rules can read from it instantly. It's purpose-built for small, frequently changing datasets like pricing tiers, country codes, routing rules, or product catalogs that your business logic depends on.

Use a Lookup Table when your data is small (hundreds to thousands of rows), changes often, and needs to be managed by business users without technical skills. Use a database when you're dealing with massive datasets (millions of rows). Lookup Tables sit in the sweet spot between hardcoded values and full database infrastructure — perfect for configuration data, reference lists, and rule parameters that non-developers need to control.

A Decision Table contains your business logic — it evaluates conditions and returns decisions. A Lookup Table contains your business data — it stores values your rules need to reference.

For example: a Decision Table might say if country = US, apply fee structure, while a Lookup Table stores the actual fee values for each country. They work together: your Decision Table reads data from your Lookup Table to make smarter decisions.

CSV, Excel (.xlsx), and JSON. CSV is best for quick data-only imports. Excel files must follow a specific format with headers and data. JSON import is also supported and used for full table exports and re-imports rather than manual data entry.

See our documentation for the required structures and examples.

Yes. When you import a CSV, it merges with your existing data. Rows with matching primary keys are updated, and new rows are added. You can choose whether to automatically create new columns from the CSV or skip them. We recommend creating a new version before major imports so you can roll back if needed.

See our documentation for details.

Yes. When you export to Excel, you'll get two sheets: one with your data and another with the Lookup Table's metadata (version info, timestamps, etc.). CSV export contains only the data itself. Both formats are perfect for sharing, backup, or analysis outside DecisionRules.

DecisionRules automatically validates your data during import and highlights any problematic cells or rows before you confirm the upload. You'll see exactly what's wrong — missing values, incorrect data types, formatting issues — so you can fix them before they go live. This means no surprises and no broken rules.

See our documentation for details on validation rules and how to resolve common issues.

This is an encoding issue. CSV files must be UTF-8 encoded for special characters to display correctly. In Excel, use "Save As" and select "CSV UTF-8" from the format dropdown (not just "CSV"). In Google Sheets, the download as CSV option automatically uses UTF-8 encoding, so you're covered.

Up to 600,000 data points per table (16 MB file size). That means 60,000 rows with 10 columns, or 120,000 rows with 5 columns. This covers the vast majority of reference data use cases — from product SKUs to regional tax rates.

If you need larger datasets, consider splitting into multiple tables or using our database connectors.

All rule types can reference Lookup Tables. In Decision Tables use Lookup Tables as predefined valid values in cells for easy dropdown selection. In Flows, use the Business Rule node to query Lookup Tables and route logic based on the results. In Scripting Rules, call Lookup Tables directly using built-in functions. The integration is native across the platform — no matter which rule type you're working in, your Lookup Tables are ready to use.

See our documentation for details.

Yes — and this is one of Lookup Tables' biggest strengths. One table can power dozens of rules across your entire workspace. This means that you store your data in one place, instead of duplicating it in several rules, then everyone reads from a single source of truth.

You have complete control. You can configure your rules to always use the latest version — when you create a new Lookup Table version, rules automatically get the freshest data. Or you can lock to a specific version, so rules stay pinned to a particular version even when you update the table. This flexibility lets you test new data safely while keeping production stable.

Not yet — currently you can only retrieve individual rows or values based on a primary key lookup (e.g., get the row where country = 'US'). Full table extraction is on our roadmap and coming soon. For now, structure your rules to query specific rows rather than loading the entire dataset. If your use case requires reading all the data every time, a Decision Table is likely a better fit.

Yes — and there are two types of history. Rule history is auto-saved every time you click Save, capturing your changes in the rule's edit history. You can browse and restore any of these auto-saves at any time. Versions are manual snapshots you create explicitly when making bigger changes. You can name these versions, compare them, and roll back to any previous version with one click.

Both types of history give you full safety and control over your data.

Permissions are fully customizable at multiple levels — space, account, team and roles. You can grant edit access to specific users, restrict others to read-only, or set up approval workflows for production changes.

See our documentation for how to configure granular access control.

Yes. Use our Management API to automate your Lookup Table workflows. You can update data, publish new versions, sync from external systems, or trigger changes based on events in your application — all without touching the UI. Perfect for nightly data refreshes, integrations with your existing tools, or automated deployment pipelines.

See our Management API documentation for details.

Be descriptive and consistent. Name tables after what they contain: Country Tax Rates not Table 3. Use clear column names: taxRate not value1. Stick to one naming pattern across your workspace — either camelCase, snake_case, or Title Case. Future you (and your teammates) will thank you.

Let the concepts guide you, not the size. Each Lookup Table should represent one logical concept — country codes, pricing tiers, product categories — organized around a single unique primary key. If your data naturally belongs together, keep it together. If it represents two different things, keep them separate.

Lookup Tables aren't relational databases, so don't try to link them. If a rule needs data from two different concepts, query two tables separately. If you find yourself needing joins or cross-table relationships, that's a sign you've outgrown Lookup Tables — use our database connectors instead.

Choose a value that's unique, stable, and meaningful. Use business identifiers like customer ID, product SKU, country code, or employee number — not names, descriptions, or anything that might change. For example: use USD not US Dollar, or PROD-001 not Widget Pro. Your primary key is how rules find the right row, so it needs to stay consistent.