Why Go Wide?

The perks of creating gigantic tables in Airtable

Hello friends! We're continuing our tour of my submissions workflow today, with an Airtable-y post about how my "wide" base set-up helps me build submission lists.

If you haven't read my earlier posts on how I track submissions in airtable and how I build sub lists, I recommend checking those out before reading further!

But as a quick refresh, what I mean by a "wide" base set-up is that there are a LOT of fields in one table – some of my tables are just shy of 200 fields.

That would be totally unwieldy in a traditional spreadsheet program like Excel; you'd get lost in a sea of data. But even though Airtable looks like a spreadsheet, it's actually a database, where you can quickly sort, filter, and hide data. You can slice up that huge underlying table into lots of different bite-sized views and quickly toggle between them, so you're only ever looking at a small section of your big table at once.

It can feel weird to build wide tables in Airtable, especially if you're used to spreadsheets. But personally, I think going wide is one of the best parts of using Airtable versus a traditional spreadsheet! It's a way to tap into the power of a database, so it's worth trying to shift your mindset.

Temporarily turning on field visibility in other views

As I said in the post on building submission lists, my first step is adding editors who like that creator's work:

I always start sub list planning with editors who have expressed a specific interest in the author or illustrator's work. This includes editors the creator has worked with on other books; editors who passed on their previous submissions but had positive feedback; and editors who have let me know that they're a fan of the illustrator's art style.

I have a series of views in my "Subs & Interest" table that track publisher interest in each of my clients' work – one view for each client. Every time an editor or art director shares feedback on a client's work, I make a note of their comment in Airtable. I have a long text field for each one of my clients where I drop in the editor or AD's comments, and I also add the client's name to a multi-select field called "Client Interest."

For example, if an editor responds to a promo update to say that they love my client Sonia Agüera's art style and would like to see more work from them, I'll add that note to the field called "SONIA AGUERA" and add "Sonia" to the Client Interest field:

Then I have a view for each client that filters based on whether their name is in the Client Interest multi-select field¹. The view pulls in some top-level info for each editor, and the comment they made about the client's work:

Remember that I’m using dummy data in screenshots of my submissions base!

I use these views when I'm building submission lists and sending out updates on a client's new art samples. Having a "wide" table makes it super easy to add editors to sub lists: I temporarily unhide the submission's status field so it shows up within the client interest view, and toggle the status field to "idea" or "first wave," etc.²

I also usually turn on visibility for the submission's "Inclusion" field as well, and summarize or copy and paste the editor's comment there so it shows up in the submission list. When I'm done, I'll hide the submission fields in the "Client Interest" view again. I also do the reverse when I'm archiving a submission³ – I'll make a client's Interest comment field visible within their submission's view, and make sure I've added all the relevant feedback from editors on that client's work (positive and otherwise) to their comment field.⁴

If I separated my data about publisher interest in a client's work and submissions in different tables, I wouldn't be able to merge data like this when it suited me. (And originally, I actually did separate this info into two different tables! But the limitations of that approach it became annoying, so later I merged it all together into one table.)

An overview of active subs and the "overlap puzzle"

Another thing I mentioned in my post about building sub lists is the editor overlap puzzle:

A sub list is not only formed of the editors I think are most likely to love a project; those editors also need to be spread across different imprints/publishing houses, and there is an unwritten rule to not "double up" on submissions with one editor. So I need to check whether an editor I want to include on a sub list is already considering another submission, and potentially wait until she closes that out to send her something else.

Right now, I primarily send out pitches for picture books, which means I am usually submitting to the same smallish group of editors who work on picture books. It's tricky to avoid accidentally sending one editor multiple projects. I needed a way to see an up-to-date overview of editors that were currently considering submissions – and I wanted it to update automatically so it would be accurate and I wouldn't have to do any extra work.

Because all my submission tracking fields are in the same "wide" table, I set up a couple views that pull together all the status fields for each of my submissions and filter them in different ways.

Subs Overview

A view I made called "Subs Overview" is the one I use most often. It shows the status of all submissions at any stage (active, forthcoming, or paused) across every editor I have in my base:

I'm really visual, so I like how this view works almost like a chart. When I'm methodically whittling down a list of ideas into a final sub list, I'll scroll down this view slowly, focusing on one of the status fields. It makes clear where there are gaps in my sub lists that I could consider filling, and where I have overlap between editors or imprints that I need to address. 

Editors with Subs

But, there *is* a whole lot of information to digest at once in that view. So I have another version of Subs Overview that I filter based on whether editors are actively considering a submission. I call this my "Editors with Subs" view, and use it to double-check that I haven't accidentally missed any points of overlap.

All the status fields are shaded green here because they are tied to a filter.

I have a bunch of overlapping filters set up to create this view – one filter for each submission status field – which each pull in records based on whether the submission status is one of the "active" status options, like "submission out" or "editor sharing with others."

Lots of fussy toggle selecting to set up this view. But it was worth it!

Note that I used the "or" field when overlapping the filter conditions, because I wanted to pull in editor records where ANY status field was active. Using "and" would look for editors where ALL the status fields were active, so it wouldn't work here.

The TL;DR of this whole post is: going wide with your table set-up allows you to see and interact with the same field in multiple views, so you can compare and contrast different sets of data. There are probably other ways to achieve everything I've shown you here by using formulas, linked fields, and/or automations. I actually experimented with a couple other workflows myself before I settled on this one! But for me, this set-up is the easiest and most straightforward. There isn't really a reason not to go ham with making huge tables in Airtable, but there are certainly perks!

1. The reason I have this multi-select field and use it for filtering is because I also make note of comments that are not positive, like if an editor tells me that they just aren't a fan of a client's work. This is really useful info! It helps me understand the editor's taste – knowing what someone does not like is as useful as knowing what they do like! And it also differentiates between not knowing how an editor feels about a client's work (maybe they'll like it?!), and knowing that they actually do not respond to a client's work. Two very different things. However, I only need the positive comments to show up in the interest view most of the time.

2. Another quick reminder: The way I add an editor to a submission list is by adjusting the submission's Status field. My sub lists filter according to that Status field being "not empty" – so any status selection, from "idea" to "first wave" to "declined," will include the editor in that project's submission list.

3. I'm going to talk about my submission archive in a future post!

4. I try to update client interest fields as the submission unfolds so the client's Interest view is always up-to-date. But sometimes I miss things. So when I'm archiving a sub I'll double-check that no useful feedback fell through the cracks.