What am I getting wrong about setting up an editorial calendar base?


#1

I am trying to create a master editorial calendar to manage my organization’s newsletters, and I suspect I’m getting stumped by both the limitations of the primary field and how to properly use the lookup field when it comes to linking records between tables.

I want both an overall view of the entire newsletter production process in one table as well as separate tables for each newsletter and its respective issues. But I need the tables to talk to each other. The issues, deadlines and story lists should populate between the master production schedule and each newsletter’s production schedule. If a staff member changes a date or story in the newsletter tables, it should automatically be updated in the master list table. But every approach I try fails and/or creates a bunch of duplicate fields in a table that I don’t understand. Sometimes I can get tables to link and sync, and later it turns into a configuration error.

I feel like I need someone else to look at my extremely simple base to see what I’m doing wrong.

What am I missing to make this work?


#2

Hi @Julie_Wittman. Let me clarify if I understand the structure of that you are trying to achieve. It sounds like it has a hierarchy something like this:

Master Schedule
_Newsletters
__Stories
__Deadlines
_Issues
__Stories
__Deadlines

If you could make a dummy table for the master list using ‘single line text’ or other ‘dumb fields’ (ones other then ‘linked’, ‘rollup’, and ‘lookup’) it’d give me a better idea of what our goal is.


#3

Sorry, I don’t understand what you’re asking, as I’m not technically proficient with spreadsheet programs in general. Do you mean make a list of the columns in each table within the base?


#4

Yep! That’s pretty much it.

Even more basic is ok though. Imagine you were explaining it over coffee and you only had a napkin to draw it on. This shallow level of depth is really helpful.


#5

I asked a colleague to take a look at my actual base, and she set up a number of views within one table that negated the need for multiple separate (but connected) tables that I had previously created. I think this approach will do the job well enough.

Thanks!