Airtable è quasi ideale per un calendario editoriale. Viste a griglia e a calendario sugli stessi dati, allegati accanto al testo, collaboratori e viste per campagna.
Passare da lì a post pubblicati è un flusso di lavoro breve, con due dettagli che decidono se è affidabile.
Campi utili da avere
| Campo | Tipo | Scopo |
|---|---|---|
| Content | Testo lungo | Il post |
| Status | Selezione singola | Draft, Ready, Published |
| Channels | Selezione multipla | Piattaforme di destinazione |
| Publish at | Data | Orario programmato |
| Media | Allegato | Immagini o video |
| Post URL | URL | Scritto indietro dopo la pubblicazione |
Il campo allegato di Airtable è il vero vantaggio rispetto a un foglio di calcolo qui: il materiale multimediale vive con la riga invece che come un URL che devi ospitare da qualche parte.
Il flusso di lavoro
1. Schedule Trigger, ogni 15 o 30 minuti.
2. Nodo Airtable, cerca record con un filtro Status = "Ready". Questo è il cancello, ed è il motivo per cui il flusso di lavoro non pubblica righe scritte a metà.
3. Filtra sulla data di pubblicazione se la riga deve controllare i tempi.
4. Costruisci il post dai campi, mappando i canali a selezione multipla sull’elenco dei canali.
5. Nodo BulkPublish, Post → Create.
6. Nodo Airtable, aggiorna il record. Imposta Status su Published e scrivi indietro l’URL del post.
Il passo 6 non è opzionale
Senza il write-back, l’esecuzione successiva trova le stesse righe ancora segnate come Ready e le pubblica di nuovo. Poi l’esecuzione dopo quella. Un flusso di lavoro che controlla ogni 15 minuti ripubblicherà lo stesso post 96 volte al giorno.
Questo è il modo più comune in cui questi flussi di lavoro vanno storti, e il sintomo è imbarazzante in pubblico.
Se vuoi cintura e bretelle, filtra anche i record che hanno già un Post URL. Due controlli indipendenti, così se uno fallisce non produce duplicati.
Allegati
Gli allegati di Airtable arrivano con degli URL, che sono ciò che passi. Due cose da sapere.
Gli URL degli allegati possono avere una durata limitata. Non costruire un flusso di lavoro che ne memorizza uno adesso e lo usa giorni dopo senza recuperarlo di nuovo.
Controlla il file rispetto alle regole della piattaforma. Airtable ospiterà tranquillamente un’immagine da 50 MB che Instagram non accetterà. Le regole sui contenuti multimediali vengono convalidate quando il post viene creato, quindi otterrai un errore chiaro invece di un fallimento silenzioso, ma il flusso di lavoro dovrebbe registrarlo da qualche parte dove lo vedrai.
Programmare rispetto a pubblicare subito
Preferisci mappare il campo Publish at su un orario programmato invece di pubblicare ogni volta che il flusso di lavoro capita di essere eseguito.
Due motivi: le righe vengono segnate come Ready quando qualcuno è alla scrivania, il che non è quando il tuo pubblico legge, e un post programmato può ancora essere annullato se la riga risulta sbagliata.
Prima le bozze
Per la prima settimana, crea bozze. Vedrai come la mappatura dei campi si comporta davvero, in particolare intorno a canali e allegati, prima che qualcosa sia pubblico.
Limiti dei piani
- Canali: Free: 3 (1 per piattaforma). Pro: 30 (2 per piattaforma). Business: 75 (5 per piattaforma).
- Post: Free: 3/giorno. Pro: 30/giorno. Business: illimitati.
- Richieste API/giorno: Free: 30. Pro: 5.000. Business: 50.000.
Un flusso di lavoro che controlla ogni 15 minuti usa 96 richieste al giorno prima ancora di pubblicare qualcosa, quindi il piano free serve per fare test, non per gestire questo in produzione.
BulkPublish pubblica su 15 piattaforme.
In sintesi
Filtra su un campo Status così le bozze restano non pubblicate, e scrivi indietro su Airtable dopo la pubblicazione così le righe non vengono riprese di nuovo, il che è come questi flussi di lavoro producono post duplicati. Mappa Publish at su un orario programmato invece di pubblicare al momento del trigger, e controlla gli allegati rispetto alle regole sui contenuti multimediali della piattaforma.