All resourcesGuidesCoursesTips

15 min read

Replacing tables with connected views

How to retrofit an existing doc with connected views.

If you find that your doc has multiple, independent tables with similar data, it's usually better to organize them as connected views of each other. By replacing separate tables with connected views, you will save time and effort by automatically syncing any changes made to the data to all views. Plus, you'll gain more flexibility in analyzing the data, as it's much easier to query a single table than it is multiple. In this guide, we'll show you an efficient way to combine independent tables and retrofit your doc with connected views.
What you'll learn:
  • How to identify tables that could be views
  • How to consolidate data into a base table without data loss
  • How to build connected views from a single source of truth
  • Change management best practices

1. Compile a list of tables you want to connect

 Tables that would make good connected views are the ones that share a common noun. Learn more about deciding if a table should be a view here. Consider using the Doc Explorer Pack to quickly pull a list of all tables in your doc. Add a checkbox column to mark which tables you plan to turn into connected views. Once you’re confident you’ve checked off all the tables to combine, add a table filter to show only the rows you’ve checked off.

2. Create a new base table

 This will be the new table where all the rows from all the separate tables will be added. Your new views will be views of this table. It’s best practice to store this main table in a “backend” page. No one will actually see or use this table, it will only be used to create views from. Add ALL columns that appear on ANY of the tables you’re looking to combine. It’s ok if only one table has a column and all the others do not; add it anyways. We’ll talk about hiding irrelevant columns in a later step.

3. Create a tagging and filtering plan

 Each of your views is going to be a filtered version of your main table. This means you need to figure out what parameters you’re going to filter on to pull the desired rows for each view. A simple plan could be to explicitly state which views a row should appear in via a select list column. The select list options would be the name of every view you plan to make. For each row, select the views you want the row to appear in. In each view, you’d filter for rows that have that view listed. This is by no means the only way to approach this, so do what feels right for you and your doc! Check out this guide for a deep dive into how to create a custom tagging/filtering system.

4. Create the views

 Go through your list of tables, and create a view of your new base table for each one. Make sure to add a descriptive title to each one. If you want your title to be the same as the original table, consider appending the original table’s title with “-original”, as all tables and views in Superhuman Docs must have unique names. For each view you create, apply the appropriate filter based on your plan from step 3. Hide any columns that are not needed for each particular view.

5. Add your rows

 Going view by view, copy the rows from your original table to the new view.
Docs tip
If the columns in your view are in the same order as your original table, you can bulk select all rows/columns and paste everything at the same time.

6. Check for duplicate rows

 Return to your main table and check for any duplicate rows. Duplicate rows can occur if you had a row listed in two or more tables. If you find duplicates, select one row to keep, and adjust the column values to ensure it appears on all of the correct views, per your filtering system. Then, delete the other rows.

7. Delete the original tables

 Compare each view to its original table. Once you are satisfied that all the rows are there, delete the original.

Replacing tables in high traffic docs

 Replacing tables with views in a frequently used doc can be a challenge logistically. Here are some tips to make the transition smoother.
Docs tip
Wondering how to see doc traffic stats? Learn how here.

Do steps 1-4 discreetly

 Create a hidden page in the doc where you create the new base table and all of the new views. Because the page is hidden, these new tables and views won’t impact or confuse the users who are using the original tables.

Freeze operations for the final steps

 When you begin adding rows to the new views, you need to avoid users adding or updating data in the original tables that you’ve already copied over as this can result in data loss. Plan and communicate a cutover date for when users stop adding new data to old tables. During the cutover period, users will cease making changes to table content. You then can move the new views from the hidden page to their live pages and complete the row transfers, steps 5-7. When all original tables have been deleted, relaunch to your team. Check out this guide for a deep dive into making the transition smooth and minimizing disruptions in workflow.

Now what?

 Retrofitting your doc is a great first step toward keeping your data clean and connected. Here are a few good next steps:

Was this helpful?

YesNo