Asana is finally rolling out Tables, a new object type for structured reference data. The help article is fairly short so far, so I’ve pulled together everything I could based on our recent testing, with a side-by-side comparison against regular tasks and projects.
TL;DR: a table is a container (basically a stripped-down version of a project) and a record is a row inside it (a stripped-down version of a task). Records are built for reference data (vendors, assets, properties, customer accounts), not for work. They have no assignee, no due date and no completion state. Instead, you reference records to the tasks, projects and portfolios that do the work.
When to use a table (and when not to)
Use a table when you need structured reference data that stays connected to work in Asana: vendors, assets, properties, customer accounts, product catalogues, locations.
Don’t use a table as a CRM / sales pipeline, a BI warehouse, a SQL database, a formula-heavy spreadsheet or a standalone automation platform. Asana is explicit about this.
Rule of thumb: if someone needs to action it by a date, it’s a task. If people need to look it up while doing their tasks, it’s a record.
Who gets it?
| Projects & Tasks | Tables & Records | |
|---|---|---|
| Plans | All plans | Advanced, Enterprise, Enterprise+ only |
| Where they live | Teams, My tasks, portfolios | Workspace level (a table belongs to a workspace and can’t be moved into another container) |
How do I get to them?
Tables don’t sit alongside your projects in the sidebar, so they’re easy to miss at first:
- Projects live under the Work mode
- Tables live under the Knowledge mode
Records vs Tasks: fields and metadata
Legend: 
supported 
not available
| Field / metadata | Task | Record | Notes |
|---|---|---|---|
| Name / title | |
|
The only required field when creating a record |
| Description | |
|
No native description field. Use a text custom field instead (text fields now support rich text) |
| Assignee | |
|
No native assignee. Use a People custom field instead |
| Due date / start date | |
|
No native dates. Use a Date custom field instead |
| Completion (mark complete) | |
|
Records are reference data, so there is no complete / incomplete state |
| Completed on / completed by | |
|
Follows from the above |
| Created on / created by | |
|
|
| Last modified on | |
|
|
| Collaborators / members | |
|
Records can be searched by a member |
| Permalink | |
|
|
| Tags | |
|
Use a multi-select field instead |
| Custom task types and statuses | |
|
|
| Basic field types | |
|
Tables support text, number, date, single-select, multi-select, people |
| Reference fields | |
|
Records can be connected to tasks, projects, portfolios, goals, teams and other records |
| Lookup fields | |
|
Pull values from a referenced record (not a task). Respects permissions, so nobody sees lookup data from records they can’t access |
| Formula fields | |
|
|
| ID (custom ID) field | |
|
|
| Timer field | |
|
|
| Time tracking fields | |
|
|
| Sections | |
|
No sections in tables to place a record in |
Records vs Tasks: features
| Feature | Task | Record | Notes |
|---|---|---|---|
| Comments | |
|
Full activity feed |
| Pinned comments | |
|
|
| Threaded comments | |
|
|
| @ mentions in comments | |
|
|
| Attachments | |
|
|
| Subtasks | |
|
Records have no parent / child hierarchy |
| Dependencies | |
|
|
| Multihoming (add to multiple containers) | |
|
A record belongs to just one table. To reuse it elsewhere, reference it from a task, project or portfolio |
| Approvals / milestones | |
|
|
| Recurrence | |
|
No dates, so nothing to recur |
| Appears in My tasks / Inbox assignments | |
|
No assignee, so records don’t land in anyone’s My tasks |
| Convert to project | |
|
Sensibly, a record cannot be converted to a table |
| Duplicate | |
|
The API has a Duplicate a task endpoint but no equivalent for records |
| Advanced search | |
|
Search for tables or record using several filters |
| Task/record-level permissions | |
|
Access can be set for specific people on an individual record |
| Rules can act on it | |
|
Can also trigger script actions  |
| Forms create it | |
|
Forms can create records from submissions |
| Import CSV | |
|
|
| Export CSV | |
|
Only CSV, not XLS like Projects |
| AI Teammates / Asana Dash can read it | |
|
One of the main reasons Tables exists: richer context for AI and automation |
| API | |
|
Dedicated /tables and /records endpoints |
| MCP | |
|
Asana’s MCP server includes create, update, search and comment tools for records |
| Webhooks | |
|
Not yet for records..? |
| Archive Project / Table | |
|
|
| Add to Starred | |
|
Tables vs Projects: the container and the Customize menu
| Capability | Project | Table | Notes |
|---|---|---|---|
| Customize menu > Fields | |
|
Removing a field disables existing values rather than deleting them, same as projects |
| Customize menu > Forms | |
|
|
| Customize menu > Rules | |
|
|
| Customize menu > Task templates | |
|
|
| Customize menu > Task types | |
|
|
| Customize menu > Bundles | |
|
|
| Customize menu > Apps | |
|
|
| List / grid view | |
|
Can create multiple List views, like in projects |
| Board view | |
|
Well, it’s a database  |
| Timeline / Gantt / Calendar | |
|
No native dates so nothing to plot |
| Dashboard | |
|
|
| Overview / Messages / Files / Pages | |
|
|
| Members | |
|
Uses Asana’s existing permission model at table and record level |
| Project roles / owner | |
|
|
| Sections | |
|
Use the Group button instead |
| Status updates | |
|
|
| Add to portfolio | |
|
|
| Save as template | |
|
|
| Duplicate | |
|
Converting an existing project to a table
If you’ve been using a project as a makeshift database (vendor list, asset register, client directory), you can now convert it to a table:
- Open the project
- Click the drop-down next to the project name
- Select Create table from project
- Choose what should be converted
Things to note before you convert:
- Project-local custom fields: add local fields to the library if you still want them in your project
- Task-only data: assignees, due dates, sections, completion status, subtasks and dependencies will get converted into custom fields (people, date, single-select, reference fields)
- Automations & Forms: early testing did not copy these features into the resulting Table; this may be supported as a fast-follow. If forms will be supported, they will likely generate a new URL.
- The original project: stays as is after conversion with the option to mark it as archived or not post conversion. You can convert a project to a table, multiple times.
Ways to import data
- CSV import into a new or existing table
- Forms that create records from submissions
- API / MCP to create and update records programmatically
Permissions in a nutshell
- Tables use Asana’s existing permission model, at both table and record level
- Individual records can be shared with specific people
- Lookups respect access: if you can’t see a record, you won’t see values looked up from it
Have you tried Tables yet? Share what you’re using them for, and let me know if you spot anything I’ve missed so we can keep this post updated, together. 
Richard Sather
Asana Solutions Partner & Forum Leader
See all of our top tips & tricks on our website.
