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 field1. The view pulls in some top-level info for each editor, and the comment they made about the client's work:

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.2

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 submission3 – 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.4

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.

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."

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!

The very first thing I set up in Airtable when I became an agent was a submission tracking base. I've since gone on to completely redesign how it works "under the hood" and added several extra bits of functionality to it that are integral to my current workflow, but the gist remains the same. And since this is the oldest part of my JGLM Airtable ecosystem, I wanted to start our tour here.

If you're brand-new to Airtable, this submissions base is a good case study to get a better sense of how it works. I find that it's easiest to learn a new program by seeing it in action!

Two quick notes before we dive in:

Because all the information about my clients' projects on submission is confidential, I duplicated my actual submissions base and filled it in with some dummy data1 for these screenshots. The entire framework is exactly the same as my real submissions tracking base though.

Also, I'm giving you a tour of how this base looks today, but I have some ideas brewing for how I'd like to tweak it further. Everything's always a work in progress! I'll update you later to share the changes I make and why I decided to make them.

Anatomy of a View

Each of my clients' projects on submission gets its own view. Because I'm on a paid Airtable plan, I can organize my views into sections. I have several sections in this "Subs & Interest" table, but for now let's focus on this (fake!) example project called Pothos in "Active Subs."

Each submission view is created by choosing which fields (columns) and filtering which records (rows) of all available fields/records in the table are visible in this particular view. I'm going to talk more about this below, but for now, I just wanted to point out those sections highlighted in light blue and light green at the top of the grid.

This view is organized into groups. The groups are based on the single select field called POTHOS / STATUS.

I really like the functionality of grouping records. Visually, it works well for my brain to see data organized this way. And whenever the field a project is grouped by is updated, the record automatically moves to the new group. There's a little animation that shows the record sliding into place.

In the screenshot above, I've split the view into two halves – the leftmost five fields are general information about each editor. These same fields appear in all of my submission views for different projects. The first four fields are pretty self-explanatory – name, title, publisher, imprint. The field called "NOTES & WISHLIST" is where I save all the information I keep on file about each editor's tastes and the types of projects they're looking for.2

The other eight fields that appear in this view are specific to tracking this particular submission. Let's take a quick look at each one:

INCLUSION - this is where I write quick notes to myself about why I've included each editor on the submission list. I also share these notes with my clients when I share the sub list with them so they have a bit of context.

SUBMITTED - the date I sent the pitch out to that editor

LAST NUDGE - the most recent date I've nudged an editor about the submission

SCHED NUDGE - the next date I'm planning to nudge. Whenever I submit a project or send a nudge, I update this field to prep for my next nudge. And I have an automation set up to send me a reminder email when this date rolls around so I don't forget. (I'll write about automations in a separate post one day!)

LAST ED. COMM - This stands for "last editor comment" and I use it to mark the date the editor gets back to me with a meaningful comment, like a pass or an update that they are sharing the project with their team. Originally, I used to update this field when editors confirmed receipt too, but I don't do that anymore because of an automation I set up that runs off this field.3

EDITOR COMMENT - I copy and paste whatever the editor says about the project here. Sometimes I'll also summarize key updates and put them in italics, like "Call with client on DATE to discuss editor's R&R notes"

NOTE - this column doesn't show up in the screenshot, but it's a place I put random things I want to remember about the sub, such as "editor is on parental leave from DATE to DATE" or "mark as ghosted if no reply by DATE"

STATUS - this column also doesn't show up in the screenshot, but you can see the data since it's the field that the records are grouped by. I keep it visible in the view so that I can easily change the status while I'm working in this view.

Under the Hood

You may have noticed that in the screenshots, all of those eight fields I just discussed actually contain the word "POTHOS." Why? Let's circle back to the beginning, with hidden fields and filtered records.

Something that I do with many of my Airtable bases is set them up to be very wide4 – in the sense that there are a LOT of fields in one table. For example, I currently have a little over 150 fields in my "Subs & Interest" tracking table that we're looking at here.

That would be totally unwieldy in a program like Excel; you'd get lost in a sea of data. But in Airtable you can slice up that huge underlying table into lots of different bite-sized views, so you're only ever actually looking at a small section of your table at once.

And that's what I'm doing with each individual project submission view – looking at a small slice of what is a big CRM5 table tracking editors and art directors.

Share Art Agenting & Airtable

So what are all those 150 fields in my Subs & Interest table? Well, a big chunk of them are for each of my clients' projects on submission. In order to have a view like I shared above for each sub, every project on submission needs to have its own field for all eight of those criteria (inclusion rationale, date submitted, etc). And because the type of information repeats (i.e. "INCLUSION") I use a tag or code word to designate which project the field relates to so the field names are all unique.

In real life, I use one descriptive word from the book's title as my tag. For example, spirits was the tag for a project called School Spirits. So the fields for that submission were called INCLUSION / SPIRITS and so on. In my fake data for this dummy base, I used flower names for all the project tags: daisy, tulip, pothos6...

To create a submission view, I toggle off visibility for all the available fields in the table except for the five fields of general information about each editor (name, title, etc.) and the eight submission tracking fields with the project's tag word.

Filtering records is more straightforward. In my real Subs & Interest table, I have over a thousand records. But I only want to see the editors on each project's submission list in my tracking view. So I set up a filter that's based on the sub's status field.

Airtable's filters are pretty intuitive. I have mine set up to only pull in records where the STATUS field for a particular project "is not empty."

Of course, I only have to set up the view with hidden fields and filtered records once, because views can be saved in Airtable. It's super easy for me to toggle between all my different project sub views and update each grid as new info trickles in.

Sharing the tracking grids

If any of my clients are reading along here, some of you will probably recognize these grids! One of my favorite things about Airtable is that you can create a link to share a read-only version of a view with anyone – they don't even need an airtable account to see it. So I offer to share a link with my clients who want to follow along with their submission.7 (I do turn off the visibility of some fields in my clients' version of the tracking view, such as the editor wishlist field and the nudge fields.)

These read-only share links have a couple of security measures you can choose to use, including needing a password to view. (The password is set for each individual share link; it's totally separate from an Airtable account password.)

The read-only views are, obviously, read-only – so you don't have to worry about anyone with the link accidentally changing the data in your base. But read-only viewers can manipulate the way information is displayed in their read-only view. For example, you can click into records to expand them, or expand individual cells where some text is cut off (such as with the inclusion notes or editor comments). It's also possible to change the sort and grouping criteria, and change the row height.

But friends! You can see all this for yourself. Go ahead and click around in the read-only view of this base you've been looking at via screenshots for the past ten minutes.

Link: https://airtable.com/appDHkl3q8isTcc1y/shri9HTwktyEXmORr
Password: ArtAgenting+Airtable

There are lots of different ways to use Airtable to track the status of submissions, and this is only one of them. If you're an agent using airtable for your subs, I'd love to hear how you're doing it differently in the comments.

Leave a comment

And despite the length of this post, I've actually only scratched the surface of my submissions tracking system. Stay tuned for what I think about when I build submission lists, how this "wide" base set-up helps me avoid doubling-up on submissions to editors, the details on those automations I teased, and more.

Thanks for following along, and if you found this helpful, please share with a friend! See you next week.

In short, it's a low-code cloud database software that's mapped onto a spreadsheet. It looks and functions like a leveled-up spreadsheet, but it's actually a database underneath, so you can do a lot of cool things with it that aren't possible in spreadsheet programs like Excel.

I think it's easiest to understand how Airtable works by seeing it in action. So let's take a look at some screenshots.

Here's a little slice of my Airtable base that tracks my clients' books. This is what's called a grid view.

We're going to unpack what “grid view” means further down so don't worry about that yet.  For now, just note that this looks an awful lot like a spreadsheet, yes? But a bit prettier and more elaborate.

Airtable's grid view is like its backbone. Every table needs to have at least one grid view1. I don't think grid views are technically where info is stored in Airtable, but I like to think of it that way in my brain. Grids are the foundation on which everything else in Airtable is built.

In the grid view, each row is called a record, and each column is called a field. This is where we start to deviate from normal spreadsheets and get into Airtable's database underpinnings.

Rows are called records in Airtable because they don't actually function like rows in an Excel grid. In Airtable (and in databases generally, I believe), each record is its own data set. Records are the building blocks of Airtable.

The left-most field (column) of a record is called the primary field. The primary field is essentially the title of the record’s data set. It describes the information contained within the record, and ideally there should be a unique name for each record. In my grid example above, the primary field is the title of each book. All the information in each record is describing that book.

Of course, lots of normal spreadsheets are organized this way too. So what's the difference between a record and a row?

The answer is mutability. With a record actually grouping a set of data together into a unit, that data can be transformed in all different kinds of ways. For example, in Airtable, each record can be expanded to display the information vertically in a list, instead of in the horizontal grid view.

I love expanding records, especially to input a lot of data about a particular record at once (like when I’ve sold a book and am adding it to my system), or when I'm trying to focus on reviewing the data for one particular record and I don't want to get distracted or confused by lots of other info in a grid view.

But expanding records is only one small way you can transform data in Airtable. There are 6 other types of views, in addition to the grid view. For example, you can transform your data into a gallery view:

… plot dates in a calendar view:

… or organize records in a kanban view:

And this is only the tip of the iceberg. There are lots more ways to view and organize your data in Airtable – even beyond the 7 types of views that you can see on the bottom left of all these screenshots. (But that's another post for another day.) Airtable describes views like this:

A view is just a different way of looking at the same underlying data. This means that if you edit the data in a record while in one view, it will change that data for all views since all views are looking at the same record. Whenever you're looking at your data in Airtable, you're always looking at your data through a view. Even if you're looking at your data through the default "Grid view" that comes with every new table, you're still looking at your data through a view.2

And that's the best part about Airtable: everything is connected. You can toggle between different views with a single click and update data in any view, and it updates everywhere. You can drag records around the calendar view to update date fields instead of keying in numbers. You can drag and drop records into different columns of a kanban board to change status fields. And so on.

Hopefully you are all thinking that this is pretty cool! And maybe you're getting ideas about how you might want to upgrade some of your own spreadsheets? Hooray! I have tricked you into getting excited about spreadsheets. Muahaha. Luckily you are in the right place, because I, too, find this very exciting3.

But before you run off and create your Airtable account, let me unpack a few more terms and features.

Anyone who cheekily scrolled down to the footnotes knows that tables are groups of records. They're the little tabs at the top of all those screenshots – basically the equivalent of an Excel sheet inside a workbook.

Bases are groups of tables. They create an ecosystem of data – basically the equivalent of an Excel workbook file. (What you're seeing in the screenshots above is my Books & Clients base.) Records and data in different tables within the same base can be connected, but information in different bases is separate and can only be connected with the paid plans of airtable4. (Let's not worry about that now though, and just consider bases as totally separate ecosystems.)

Workspaces are the top-level organization of Airtable. They contain bases, and that's it. Your payment plan is tied to workspaces. If your base lives inside a Free plan workspace, then that base has the capabilities and features associated with a free plan. If you have 5 bases within one Free plan workspace, then all 5 of them are on the free plan.

Each Airtable account can have any number of workspaces that you want, but in most cases, you probably only want to have one. The reasons are complicated, so I'll go into more detail in a future post. For now, if you're running off to sign up for Airtable as soon as you finish reading this post, just create a free workspace and stick all your bases in it.

Last but not least! I wanted to circle back to fields. I already mentioned that fields are the vertical columns of a grid view, but then I whizzed off and started talking about records and views before I could dig into what makes fields special and different from mere columns.

Fields are the containers that store your data within each record. There are many different types of fields that can be used to store and display your data in different ways.

There is of course, the vanilla/straightforward field type for text. But you can also set field type to store attachments (like the cover images in my examples above), dates, checkboxes, select fields, formulas, and lots of other options.

The magic behind setting fields to hold specific types of data in specific ways allows Airtable to transform your data into different views – for example, date fields can be used to create calendar views, and kanban boards are organized around single select fields.

But there are smaller benefits too, like being able to key in or adjust dates in date fields via a little calendar that pops up when you click them, or expanding long text fields to a pop up window where you can see all the text within that field.

There are dozens of types of fields, and we'll definitely dive deeper into many of them in future newsletters.

But for now, I hope this gives you the gist of how Airtable works. Drop any questions you have in the comments! And stay tuned for more scintillating spreadsheet content next month.