Using Airtable to Collaborate on a Writing Project

Ready to Publish
Ready to Publish
Publish on
Hide Page Cover
Hide Page Cover
Hide Date
Hide Date
Related Posts
Custom HTML
Meta Title
Meta Description

Using Airtable to Collaborate on a Writing Project

We are currently working on two major writing projects (Link: For our edited collection on Toxic Cultures in Higher Education, we use Airtable to track tasks for this writing project.

Why Airtable?

For many reasons, there are four editors, none of whom work at the same institution that co-edit this edited book collection. Almost all of our work is done asynchronously. Working asynchronously is typical for edited book collections. A lot of trust must be established with your collaborators before starting a project that takes this much time and effort. However, even when you trust your co-editors, the project can become very frustrating. We use Airtable to manage the project in a streamlined way so we can simplify editing this book collection as much as possible.
There are a lot of moving parts to ensure an edited collection is completed on time. When you’re collaborating with many people (4 in our case) then you need to find a project management system that lets you create an environment just for that project that is easy to use and can let you set permissions to segment areas of the project for the correct collaborators.

What Makes Airtable Work for Us

We use Airtable as our project management software for this edited collection. In Airtable, we can create views and set permissions for each view. Presently, we have created 10 views, and we haven’t even sent out an email with final decisions to the submitters. I’m sure we will be creating more views as we move along this process.

The Views We Created In Airtable

First, we created a Form view that was distributed in email communications soliciting proposals from librarians.
As we designed the base in Airtable, the first view we made allowed us to see all the fields with every detail in one table. This is where all the information from the Form we used to collect submissions went. As submissions were turned in we were able to count and read, if we wanted, the proposals. Fields we included in this table include first and last name of all authors, institutions, a link to a Google Doc,
Then we designed a view to see each editors’ comments and decisions about each proposal submitted. We named this view “CfP Review (all)”. This view gave us a birds-eye view of the progress of the editors.
Third, we created four separate views for each editor. We named each view “CfP | editor’s name.” In each view, the editor can filter and sort each field as they see fit.
Fourth, we designed a view named “Decisions” where we can see each editor’s decisions. This allows us to make a final decisions based on our co-editors’ decisions for each submitted proposal.
We received many more submissions than we expected for this edited collection. So as we looked at the decisions from each of the editors, we decided to create a view for “Decisions, Categories, and Vol.” In this view, we could categorize the submissions so create an order for the book in its final format.
Finally, we made a view called “Reevaluate.” In this view, the editors were able to review and make a final decision on the submissions labeled Consider. We filtered and sorted the view so only the submissions marked “Consider” were in the view. This made it easier for the editors to focus on just those submissions that needed a final pass. What is neat about Airtable was when we shared the view we toggled on the ability to allow data in this view to be synced to other bases. This mean we don’t have to manually change the Final Decision field after all the editors complete this task.