Create a table

Concepts covered

Step breakdown

1. Open TablesStart in the Tables area and confirm what the real screen is showing.
2. Inspect product behaviorUse screenshots and visible product states to understand what the screen does, why it exists, and how teams use it.
3. Connect the platformSee how the screen connects to agents, workflows, records, activity, channels, integrations, or ownership.

What a Studio Table is

A Studio Table is a structured data store that lives inside the Frontline platform. It holds rows and columns — like a spreadsheet — but is readable by agents, writable by workflows, and visible to operators in Studio.

Tables fill the gap between CRM records (full customer memory) and raw code variables (invisible to teammates). Use a table when the data needs to be inspectable, editable, and usable by automation.

When to use a table instead of CRM

Use a table for operational reference data that is not customer-specific: territory assignments, routing rules, campaign lists, availability windows, qualification thresholds, or competitor maps.

Use CRM records for customer-specific memory: People, Companies, Deals, Tickets. If the data row is about a customer, it belongs in CRM. If it is about how the operation works, it belongs in a table.

Creating the table

Open Tables in Studio and create a new table with a clear operational name — 'Territory Routing', 'Lead Sources', 'Qualification Criteria'. Add columns for each field the workflow will read or write: owner, region, threshold, status, last updated.

Populate the table with real values before connecting it to a workflow. A table that is empty when a workflow runs produces either an error or a silent wrong branch — both are hard to debug.

Connecting tables to workflows

Once the table has data, add a Table Action node to any workflow that needs to read or write it. The node can look up a row by a field value (e.g. find the territory owner for a given postal code), create a new row, update an existing row, or append data after an event.

Tables keep the operating rules outside the workflow logic so non-technical operators can update values — like changing territory assignments — without editing the workflow itself.

Operational playbook

Use Create a table as part of the Frontline Studio Tables operating loop: inspect the current product state, confirm the source context, and decide what should happen next.

The goal is not to memorize screens. The goal is to understand how the product surface supports repeatable work, AI assistance, and accountable handoff.

Best practices

Start with the operational job before changing configuration. Name the owner, define the trigger or source context, and decide how the result should be reviewed.

Prefer narrow, inspectable setups over broad automation. Teammates should be able to explain why the system took an action from the visible product state.

Troubleshooting

If the result does not match expectation, check the source context first, then permissions, connected integrations, required fields, workflow logs, and any AI-generated output used by downstream steps.

When in doubt, compare the latest product state with the related record, activity, or workflow execution so debugging starts from evidence rather than guesswork.

FAQs

Related workflows