A useful blog post needs more than a topic and a prompt. The AI needs to know who the article is for, what it should accomplish, how it should be structured, which keyword anchors it, and what source material it can trust. More importantly, it needs the experience, examples, opinions, and case studies that only you can provide.
This playbook shows you how to build a workflow that separates those jobs instead of asking the AI to solve everything in one pass. The field names shown here are one working example, not a required schema. Your version can live in Airtable, Notion, Sheets, Supabase, or a custom application. Preserve the purpose of the records, context, checkpoints, and handoffs while adapting the structure to your tools.
Your build begins with a place to store one record for every blog post. Each time you run the workflow, you select the Brand, intended audience, content goal, article type, writing tone, keyword, and any available research or source material. Your prompt or automation uses that context to generate two things at the same time: a proposed outline and a set of clarifying questions.
The outline gives the article its structure. The questions give you a deliberate place to add the material the AI cannot know on its own: what you have tried, what happened, what failed, what changed, what clients have experienced, and what you actually believe about the topic.
Only after that context is captured do you generate the draft.
- Brand records: the default voice, positioning, language rules, and business context
- Persona records: the complete audience profiles you will pass into generation
- Blog Post Prompt records: at least one reusable article structure, such as a how-to, case study, comparison, or thought-leadership prompt
- A working database: Airtable, Notion, Sheets, Supabase, or another place where the blog record and its linked context can live
- An AI tool: the model you will use manually or connect through an automation
Each blog post needs a selected Blog Post Prompt, one primary keyword, and source notes or a transcript. A format-specific Style Guide, linked Research, originating Idea, supporting keywords, and supplied links are optional layers you can add when available.
Details
Complete the article brief, context, keywords, links, and source material.
Outline
Review, edit, regenerate, or approve the proposed article structure.
Questions
Add firsthand experience, examples, case studies, results, and opinions.
Draft
Generate from the complete brief, current outline, and saved answers.
Publish
Create the metadata and move the approved article into the publishing system.
The clarifying questions are optional. The knowledge they collect is not. You can skip the questions and generate a draft immediately, but you should expect considerably more editing. When the AI reaches a section that calls for a real example or specific experience and you have not supplied one, it can only stay generic or invent something plausible. Neither produces an article worth publishing.
Brief answers are enough. A rough story, failed experiment, customer objection, or a few sentences explaining your position gives the AI material it can develop without pretending it knows your history.
Do not ask the AI to invent authority. Give it the structure, then add the experience that makes the article yours.
A reusable Blog Post table, record structure, and generation workflow you can run for every article. Each finished record holds the complete production history and remains the source of truth after publication.
A Blog Post Prompt is a reusable structure for a type of article you publish repeatedly. Create these as separate records so the author can select a format without pasting or rewriting its instructions for every post.
Start with one useful format. Add more only when they represent meaningfully different article structures. A how-to guide, case study, comparison, list article, and point-of-view article may each need a different prompt record.
Store Prompt Name, Article Type, Structure Instructions, and Status. The Structure Instructions should describe the expected sections and reasoning, not contain the Brand voice or Persona. Those are linked separately on each Blog Post record.
A clear selection label, such as Practical How-To, Client Case Study, Tool Comparison, or Founder Point of View.
The broad format used for filtering and reporting. Keep the options limited to formats the business actually publishes.
The reusable requirements for the introduction, section progression, evidence, conclusion, and call to action. Do not include article-specific facts or keywords here.
Use Active and Archived. Filter the Blog Post Prompt field so authors select only active structures.
Start with one place to store every blog post. If your operating system already has a general Content table, add Blog Post as a content type and add the fields below. If it does not, create a dedicated Blog Posts table.
One row or record should follow the article from the first working title through outline, questions, draft, approval, and publication. Do not create separate disconnected documents for each stage. The value of the workflow comes from keeping the original direction, human answers, generated work, and publishing details together.
The field names can change to match your tools. The jobs those fields perform should not.
Create the table and required fields first. Run the generation steps manually in your AI tool and paste the results back into the record. Once the workflow produces reliable articles, connect the same fields through Make, Zapier, n8n, or your own application.
Input fields hold the direction you provide. Generated fields hold the outline, questions, draft, and metadata the workflow creates later. Keeping both on the same record makes regeneration predictable and preserves the article's history.
The internal starting title or topic direction. It does not need to be the final headline; the outline and draft can improve it later.
Connect the article to the Brand record containing its voice, positioning, excluded language, business context, and default writing rules.
The person whose name and point of view the article represents. This matters when a company publishes work from multiple founders, experts, or client voices.
The saved prompt that defines the article type and structure: how-to, listicle, case study, comparison, thought leadership, or another format you regularly publish. Filter this field to active Blog Post prompts.
How this article should sound inside the selected structure. The tone adjusts the delivery; it does not replace the Brand voice or determine the article type.
The model used for outline and draft generation. Store it on the record so you can trace output differences and change models without rebuilding the workflow.
The specific Persona this article is written for. Pass the full Persona profile into generation, not only its name.
The business outcome the article should support. The goal guides emphasis and the call to action without turning every article into sales copy.
A format-specific guide built from real examples of how this Brand writes this kind of blog post. If no Style Guide is selected, fall back to the broader Brand voice.
A Research record that informed the article. Pass its useful source material and analysis into generation instead of relying on the AI to reconstruct it.
The idea, observation, request, or planning record that started the article. This preserves the connection between planning and production.
Use one primary keyword or search phrase. It anchors the headline, H1, article direction, and meta description. Do not ask the workflow to rank one article for five unrelated primary terms.
Secondary terms, related questions, and natural variations that support the primary keyword.
Existing pages, articles, offers, or resources on your own site that should be linked when relevant.
Original sources, references, research, or supporting material the article may cite. Supplying the link does not remove the need to verify the claim.
The offer, product, booking page, or disclosed affiliate destination the article may support when it fits the selected goal.
The raw material the AI builds from: your angle, key points, hook ideas, transcript excerpts, factual notes, non-negotiable claims, and anything the finished article must include.
The proposed title, introduction direction, headings, section purpose, and conclusion path. Store the edited version, because this is what the draft-generation step should read.
Up to five focused questions and the author's saved answers. The simplest build stores the pairs in one structured field. A more advanced build can use related Question records with Question, Answer, Order, and Blog Post fields.
The article generated from the current brief, outline, and saved answers. Keep it on the parent record so edits and regeneration never lose the source context.
The search description created after the draft is approved. Keep a visible character count in your interface when possible.
A short summary for archive pages, previews, feeds, or the destination CMS.
The URL-safe path for the article. Review it before publishing; changing a slug after publication can break links unless redirects are configured.
The final public destination. Save it back to the record so downstream emails, social posts, guest assets, and tasks all use the same link.
An estimate calculated from the approved word count. This can be generated by the workflow or calculated with a formula.
Use statuses that match your real approval path. At minimum: In Progress, Approved, Scheduled, Published, and Archived. Teams can add Needs Review or Revisions when those states represent actual handoffs.
The planned or actual publication time. This field can feed the shared working calendar and trigger a publishing automation.
The destination site's editorial category or taxonomy. Keep this aligned with the CMS instead of creating a second unrelated category system.
Harbor & Pine Operations is a fictional consultancy for small creative agencies. This example shows the level of specificity a record needs before outline generation. Replace every value with the equivalent decision from your own business.
How to Stop Losing Client Decisions in Slack
Harbor & Pine Operations
Maya Chen, founder and operations consultant
Practical How-To: define the operational problem, explain the cost, teach a repeatable process, show an example, and end with the next action.
Owner of a 5 to 20 person creative agency whose team serves several clients at once and relies heavily on Slack.
Generate qualified consultation requests by demonstrating a practical client-operations method.
Educational, direct, and conversational
client communication process
agency client communication, document client decisions, Slack client management
Three projects lost scope decisions because approvals stayed in Slack threads. Our fix was a decision log with owner, date, decision, affected deliverable, and source link. Review it during the weekly client call. One client reduced repeated approval questions from several each week to one or fewer after the first month. Do not claim Slack is the problem; the problem is treating chat as the permanent record.
/services/agency-operations-audit
In Progress
Writing Tone examples
Analytical, Case Study / Example-Based, Contrarian, Conversational, Educational / Explainer, Inspirational, Instructional, List-Based, News / Trend, Persuasive, and Storytelling.
Content Goal examples
Appointment Booking, Consultation Request, Drive Product Trials, Drive Sales / Revenue, Generate Leads, Increase Brand Awareness, Product Purchase, Support Customer Retention, and Thought Leadership.
You do not need to reproduce these dropdown values exactly. Use the tones and goals your business actually needs. The important part is that every article makes an explicit audience, structure, tone, goal, and keyword decision before generation begins.
Use this prompt once to turn the field map into a table, form, and working views in your chosen tool. The generation prompt belongs to the next stage, after a form submission has created the Blog Post record.
Show the full prompt
I want to build a reusable Blog Post workflow in [AIRTABLE / NOTION / GOOGLE SHEETS / SUPABASE / MY OWN APP]. Help me create the database structure. I am building my own operating system, not recreating a specific interface.
Create a Blog Posts table and a linked Blog Post Prompts table. One Blog Post record must follow an article from the initial brief through outline, clarifying questions, draft, approval, and publication.
BLOG POST PROMPTS TABLE
- Prompt Name: single-line text, required
- Article Type: single select, required
- Structure Instructions: long text, required
- Status: single select with Active and Archived, required
Create at least one example prompt record. Keep Brand voice, Persona, keywords, and article-specific facts out of this table because the Blog Post record supplies them for each run.
INPUT FIELDS
- Working Title: single-line text, required
- Brand: linked Brand record, required
- Author: person or text, required
- Blog Post Prompt: linked Blog Post Prompt record filtered to Active, required
- Writing Tone: single select, required
- AI Tool to Use: single select, recommended
- Intended Audience: linked Persona record, required
- Content Goal: single select, required
- Style Guide: linked record, optional
- Research: linked record, optional
- Originating Idea: linked record, optional
- Primary Keyword: single-line text, required; allow one primary keyword only
- Supporting Keywords: long text or multi-value, optional
- Internal Links: URL list, optional
- External Links: URL list, optional
- Offer / Affiliate Links: URL list, optional
- Source Notes / Transcript: long text, required
GENERATED AND EDITABLE FIELDS
- Outline: long text or structured content
- Clarifying Questions & Answers: structured text or related records; allow no more than five questions
- Working Draft: rich text or long text
- Meta Description: long text
- Excerpt: long text
- Website URL Slug: single-line text
- Blog Post URL: URL
- Reading Time: calculated number or text
WORKFLOW FIELDS
- Status: single select with In Progress, Approved, Scheduled, Published, and Archived; add Needs Review or Revisions only if the workflow needs them
- Scheduled / Published Date: date and time
- Blog Category: single or multi-select aligned with the destination CMS
Then show me:
1. The final table schema with the best field type for this tool
2. Which linked tables must already exist
3. A form or record layout grouped into About the Post, Audience and Angle, Source Material, Generated Work, and Publishing
4. A working view for articles in progress
5. A review view for articles awaiting approval
6. A calendar view using the scheduled or published date
7. How to preserve the edited outline and saved answers when the draft is regenerated
Do not build the social, email, video, image, or task workflows yet. Leave relationships available so those downstream content workflows can connect to the approved Blog Post record later.You have one Blog Post record that can store the setup fields, linked context, generated outline, clarifying answers, draft, and publishing details without overwriting earlier work.
This stage turns a completed Blog Post record into two saved outputs: an editable outline and up to five clarifying questions.
The questions are designed to uncover the author’s real experience, examples, process, results, failures, and opinions before the article is written. They are optional, but skipping them usually creates more editing because the draft has less firsthand material to work with.
Use the fields and linked records already created in Section 01. Do not create a second context table or copy the same field definitions into this stage.
When this stage is complete, the Blog Post record contains a reviewed outline and any saved answers. Both remain editable and are retrieved later when the user generates the draft.
Native trigger
Use your database tool’s “when a form is submitted” or “when a record is created” trigger. Pass the new Blog Post record ID into the next action.
Webhook trigger
Send the successful form submission to Make, Zapier, n8n, or your own endpoint. Include the saved Blog Post record ID so the automation can retrieve the record.
Manual fallback
If your form cannot start an automation, create a view of records with an empty Outline field and run the workflow from a button or scheduled check.
Start automatically after a successful form submission. Use the saved record ID as the handoff, not the temporary form payload. The automation should reopen the record and retrieve its linked records before it calls the AI.
1. Create the record
The form writes the user’s selections and source material into a new Blog Post record. The database returns the unique ID for that saved record.
2. Start once
The successful submission sends that record ID to the automation. Add a condition that the Outline field must still be empty so retries do not create duplicate work.
3. Retrieve the context
Reopen the Blog Post record, then retrieve the full selected Brand, Persona, Blog Post Prompt, Style Guide, and Research records. A form usually stores their IDs or names, not their complete contents.
4. Validate
Confirm the required fields from Section 01 are present. If something is missing, stop the run and return the record for completion instead of asking the AI to fill the gap.
5. Generate
Map the retrieved values into Prompt 02 and send it to the selected AI model. Request one structured response containing the outline and no more than five questions.
6. Parse the response
Separate the proposed title, outline, and question set. If your tool supports structured JSON output, use it; otherwise split the labeled sections returned by the prompt.
7. Update the record
Write the proposed title and outline to the Outline field and write the questions to their own field or related records. Keep the Blog Post status In Progress.
8. Hand off for review
Open the saved record or notify the user that the outline is ready. The user can edit the outline, change a question, add answers, or skip the questions before generating the draft.
Show the trigger and action map
TRIGGER
Event: Blog Post setup form submitted successfully
Input: {{blog_post_record_id}}
RUN CONDITIONS
- The Blog Post record exists
- Required setup fields are present
- Outline is empty
ACTIONS
1. Retrieve the Blog Post record by ID
2. Retrieve the full linked Brand record
3. Retrieve the full linked Persona record
4. Retrieve the selected Blog Post Prompt
5. Retrieve the Style Guide and Research when selected
6. Map those values and the Blog Post fields into Prompt 02
7. Send Prompt 02 to the selected AI model
8. Parse Proposed Title, Outline, and Clarifying Questions
9. Save Outline and Clarifying Questions separately on the same Blog Post record
10. Notify the user or place the record in an Outline Ready review view
ON FAILURE
- Do not write a partial outline over existing work
- Log the failed step and error returned
- Keep the record available for correction and a manual retryShow the full prompt
You are helping me plan a blog post. Create the outline and the clarifying questions in the same response. Do not write the article yet.
ARTICLE DETAILS
Working title: {{working_title}}
Author: {{author}}
Content goal: {{content_goal}}
Writing tone: {{writing_tone}}
Primary keyword: {{primary_keyword}}
Supporting keywords: {{supporting_keywords}}
Internal links: {{internal_links}}
External links: {{external_links}}
Offer or affiliate links: {{offer_links}}
LINKED CONTEXT
Brand voice and business context: {{brand_context}}
Intended audience Persona: {{persona_context}}
Selected Blog Post Prompt: {{blog_post_prompt}}
Format-specific Style Guide, if selected: {{style_guide}}
Linked Research, if selected: {{research}}
Source notes or transcript: {{source_notes}}
INSTRUCTIONS
1. Use the selected Blog Post Prompt to determine the article type and structure.
2. Use the Style Guide for format-specific writing patterns when one is provided. If it is blank, use the Brand voice as the writing default.
3. Use the Persona to decide what the reader already knows, what needs explaining, and which problems or outcomes matter most.
4. Build a useful outline with a proposed final title, introduction direction, H2 and H3 sections, the purpose of each section, and a conclusion or next step aligned with the Content Goal.
5. Use the primary keyword naturally in the proposed title, H1 direction, and appropriate sections. Use supporting keywords only where relevant.
6. Do not invent personal experience, client examples, case studies, results, quotes, statistics, or factual claims.
7. After the outline, identify only the missing firsthand knowledge that would make the article more accurate, original, or useful.
8. Ask no more than five clarifying questions. Ask fewer when the source material already provides enough firsthand context.
9. Tie every question to a specific section or gap in the outline. Prioritize real experience, examples, processes, outcomes, failures, objections, and the author's actual point of view.
10. Do not ask for information already present in the supplied context. Do not ask generic questions that will not materially change the draft.
RETURN EXACTLY
PROPOSED TITLE
[One title]
OUTLINE
[Introduction direction]
[H2 and H3 structure, with one or two sentences explaining what each section must accomplish]
[Conclusion or next-step direction]
CLARIFYING QUESTIONS
Q1. [Question]
Used in: [outline section]
Why it matters: [the gap this answer will fill]
[Repeat only as needed, never exceeding five questions. If no questions are needed, say: "The supplied context is sufficient to draft without additional questions."]
STOP after the questions. Do not draft the article.Write the outline into the Outline field and the question-and-answer pairs into their own field or related records. Do not store the entire AI response as one undifferentiated block. The draft workflow needs to retrieve the current edited outline and the saved answers independently.
The user has reviewed the outline, answered any questions that will materially improve the article, and is ready to generate the first draft from those saved records.
The outline automation produced questions because it found specific gaps that would make the article more accurate, useful, or original. This stage gives the author a simple place to answer those questions before drafting begins.
This is a human-input step, not another generation step. The answers do not need to sound polished. They need to be true and specific enough for the drafting prompt to use: what happened, what changed, what failed, what the author believes, or what a real customer experienced.
Build this checkpoint inside the database, form tool, or application you already use. The interface can be simple. The important part is that each answer stays connected to its question, its outline section, and the parent Blog Post record.
When this stage is complete, the current outline has been reviewed and each useful question has either a saved answer or a deliberate skip. The record is ready for the author to request a draft.
A few honest sentences are usually more valuable than a polished paragraph. Do not turn answering into a second writing assignment. The drafting step will shape the material later.
Simple build
Store the numbered questions and their answers in one structured long-text field on the Blog Post record. Preserve the question, outline section, reason, answer, and skipped state for each item.
Relational build
Create related Question records with Blog Post, Order, Question, Used In, Why It Matters, Answer, and Status fields. Use this when your application needs individual answer forms, completion tracking, or reusable views.
1. Show the approved structure
Keep the current edited outline visible while the author answers. Context helps them understand what the question will change in the finished article.
2. Preserve the question context
Display the question with its “Used in” section and “Why it matters” note. Do not reduce the record to a list of questions with no connection to the outline.
3. Accept rough answers
Provide a long-text answer field. Allow notes, fragments, examples, objections, numbers, and links. The author should capture the truth now and improve the prose in the draft.
4. Allow a deliberate skip
Questions are optional. Give the author a way to mark one Not Applicable or Skipped rather than forcing an invented answer or leaving its state ambiguous.
5. Save immediately
Write every answer back to the Blog Post record or its related Question record. The draft automation should retrieve saved values, never temporary form state.
6. Make drafting explicit
Add a Generate Draft button, action, or status transition. Do not start drafting merely because the last answer field changed; the author should decide when the source material is ready.
Show the field map
PARENT RECORD
Blog Post: {{blog_post_record_id}}
Current Outline: {{outline}}
REPEAT FOR EACH QUESTION
Order: {{question_order}}
Question: {{question}}
Used In: {{outline_section}}
Why It Matters: {{reason}}
Answer: {{answer}}
Status: Unanswered / Answered / Skipped
DRAFT READINESS
- The Outline is not empty
- The author has reviewed the questions
- Each question is Answered or deliberately Skipped
- The author explicitly requests draft generationIf the author skips a question, the draft may still proceed. The drafting prompt should write that section in general, supportable terms or keep it concise. It should never create a personal story, client result, quotation, or opinion simply because the outline appears to call for one.
The useful answers are saved with their questions, skipped gaps are visible, and the author has explicitly chosen to generate the draft.
This stage turns the approved outline, complete brief, trusted source material, and saved answers into a full Working Draft. Drafting should apply the decisions already made instead of reopening the article’s audience, angle, structure, or goal.
The approved outline controls the structure. Saved research and source notes support factual material. The answers supply firsthand experience and point of view. Brand, Persona, tone, and the selected writing guides control how the article communicates.
Build the generation action so it always retrieves the current saved values. If the author edits the outline or an answer, the next run should use those edits rather than a cached copy from the first generation.
When this stage is complete, the Blog Post record contains an editable Working Draft generated from the current source record. Status remains In Progress until the author approves the article.
The approved outline wins. The Blog Post Prompt can guide format and delivery, but it should not add sections or reverse structural decisions the author already approved.
1. Confirm readiness
Require a non-empty Outline. If questions exist but none have answers, warn the author that the article may be generic and let them choose whether to continue.
2. Retrieve the current record
Pull the edited outline, question-and-answer pairs, article brief, source notes, and the full linked Brand, Persona, Blog Post Prompt, Style Guide, and Research records.
3. Generate the full article
Map the retrieved values into Prompt 04 and send them to the selected AI model. Request one complete article that follows the approved structure.
4. Validate the response
Confirm that a complete response was returned and that its headings follow the outline. Reject an empty, partial, or error response before writing anything to the record.
5. Save without erasing context
Write the article to Working Draft. Leave the Outline, questions, answers, research, and source notes untouched so the record still explains how the draft was produced.
6. Hand off for review
Notify the author or place the record in a Draft Ready view. They can edit directly, revise an input and regenerate, or approve the article when it is ready.
Generate a new draft from the complete current inputs; do not ask the model to patch its previous prose. Before replacing an existing Working Draft, preserve the earlier version through your tool’s version history, a Draft Versions table, or a duplicate field. Regeneration is only safe when the author can recover a better earlier draft.
Show the trigger and action map
TRIGGER
Event: Author explicitly requests draft generation
Input: {{blog_post_record_id}}
RUN CONDITIONS
- The Blog Post record exists
- Outline is not empty
- If questions exist and none are answered, warn but do not block
ACTIONS
1. Retrieve the Blog Post record by ID
2. Retrieve the current edited Outline
3. Retrieve saved Clarifying Questions and Answers
4. Retrieve the full linked Brand, Persona, Blog Post Prompt, Style Guide, and Research records
5. Map the current values into Prompt 04
6. Send Prompt 04 to the selected AI model
7. Validate that the response is complete and follows the outline
8. Preserve the existing Working Draft when one exists
9. Save the new response to Working Draft
10. Leave all source and context fields unchanged
11. Keep Status In Progress and notify the author that the draft is ready
ON FAILURE
- Do not overwrite an existing Working Draft
- Do not save a partial model response
- Log the failed step and returned error
- Keep the record available for correction and a manual retryShow the full prompt
You are writing a blog post from an approved plan. Use the approved outline as the structural authority and use only the supplied record, source material, and research to support the article. Do not invent firsthand experience or unsupported facts.
ARTICLE DETAILS
Working title: {{working_title}}
Author: {{author}}
Content goal: {{content_goal}}
Writing tone: {{writing_tone}}
Primary keyword: {{primary_keyword}}
Supporting keywords: {{supporting_keywords}}
Internal links: {{internal_links}}
External links: {{external_links}}
Offer or affiliate links: {{offer_links}}
LINKED CONTEXT
Brand voice and business context: {{brand_context}}
Intended audience Persona: {{persona_context}}
Selected Blog Post Prompt: {{blog_post_prompt}}
Format-specific Style Guide, if selected: {{style_guide}}
Linked Research, if selected: {{research}}
Source notes or transcript: {{source_notes}}
APPROVED OUTLINE
{{outline}}
CLARIFYING QUESTIONS AND SAVED ANSWERS
{{questions_and_answers}}
INSTRUCTIONS
1. Follow the approved outline’s title direction, section order, headings, and section purpose. The approved outline wins if another supplied instruction conflicts with it.
2. Use the Style Guide for format-specific writing patterns when one is provided. If it is blank, use the Brand voice as the writing default.
3. Use saved answers for every personal example, client story, case study, result, failure, process, or statement of the author’s opinion. Do not create firsthand material that is not present.
4. Use source notes and linked Research for factual claims. Do not fabricate statistics, quotations, studies, links, or attribution. When the supplied material does not support a claim, omit it or state the point more narrowly.
5. If an outline section expected firsthand material that was not supplied, write it in concise, general, supportable terms. Do not imply that the author personally experienced it.
6. Use the primary keyword naturally in the title and introduction. Preserve the approved headings; use the keyword in a heading only when the approved outline already supports it. Use supporting keywords only where they fit naturally.
7. Add supplied links only where they are contextually relevant. Do not invent anchor text that misrepresents the destination, and do not add links by quota.
8. Write for the Persona’s stated knowledge level. Explain what the reader needs without padding the article with background they already know.
9. Match the Content Goal in the conclusion and call to action. Do not turn an educational or thought-leadership article into a sales pitch.
10. Write connective and explanatory prose as needed, but keep every substantive claim traceable to the supplied record or its linked source material.
RETURN
Return only the complete article with its title, approved heading structure, body, and conclusion. Do not include planning notes, citations you were not given, or commentary about the writing process.The author has edited or regenerated the Working Draft as needed and explicitly changed Status to Approved.
Publishing has two separate jobs. First, prepare the metadata and destination fields the approved article needs. Second, publish or schedule the article in its content management system. Keeping those jobs separate gives the author a final review point before anything becomes public.
Your workflow can support a manual path, an automated path, or both. In a manual build, the author copies the approved article and its metadata into the CMS. In an automated build, an explicit Publish action or scheduled time sends the same saved fields through the CMS integration.
The Blog Post record remains the source of truth after publication. Save the final public URL back to it so later emails, social posts, internal links, and reporting workflows retrieve the same destination.
When this stage is complete, the record contains reviewed metadata and reading time, the article is live, its public URL is saved, and Status is Published.
Downstream workflows should retrieve Blog Post URL from the parent record instead of storing separate hardcoded copies. If the destination changes, correct it once at the source.
Part 1 / Prepare
When Status becomes Approved, generate any missing Meta Description, Excerpt, and Website URL Slug. Calculate Reading Time, save the values separately, and let the author review them. Keep Status Approved.
Part 2 / Publish
Only an explicit Publish action or scheduled time should move the article to the CMS. Save the confirmed live URL and change Status to Published only after the destination reports success.
Manual publishing
Copy the Working Draft, Meta Description, Excerpt, Slug, and Blog Category into the CMS. After the page is live, paste its public URL into Blog Post URL and change Status to Published.
Automated publishing
Map the saved fields to the CMS API or integration. Store the destination’s post ID as well as its public URL if the integration returns both; the ID makes later updates safer.
Scheduled publishing
Set Status to Scheduled and save the intended date and time. Keep it Scheduled until the CMS confirms publication, then save the live URL, actual publish time, and Published status.
Failed publishing
Keep the last valid status and preserve the approved article. Log the destination error and allow a manual or automated retry without regenerating metadata or overwriting user edits.
Calculate Reading Time as the article word count divided by 225, rounded up to the next whole minute with a minimum of one minute. Validate the meta description’s character count in the workflow after generation; do not rely on the AI to count characters perfectly.
Show the trigger and action map
TRIGGER
Event: Blog Post Status changes to Approved
Input: {{blog_post_record_id}}
RUN CONDITIONS
- Working Draft is not empty
ACTIONS
1. Retrieve the approved Working Draft, Primary Keyword, and Blog Category
2. Map those values into Prompt 05
3. Send Prompt 05 to the selected AI model
4. Parse Meta Description, Excerpt, and Website URL Slug
5. Validate the response and Meta Description character count
6. Save generated values only into fields that are empty
7. Preserve any metadata the author has already edited
8. Calculate Reading Time as ceiling(word count / 225), minimum 1
9. Keep Status Approved and notify the author that the publishing package is ready
ON FAILURE
- Do not overwrite existing metadata
- Log the failed step and returned error
- Keep Status Approved and allow a manual retryShow the full prompt
You are preparing an approved blog post for publication. Do not rewrite the article. Generate only the metadata requested below from the article’s actual content.
APPROVED ARTICLE
{{working_draft}}
Primary keyword: {{primary_keyword}}
Blog category: {{blog_category}}
INSTRUCTIONS
1. Write a complete meta description no longer than 160 characters, including spaces. Reflect the article accurately and use the primary keyword naturally. Do not oversell the content.
2. Write a two- or three-sentence excerpt for an archive page, feed, or preview card. It must stand on its own and must not repeat the meta description word for word.
3. Propose a concise URL slug. Use lowercase letters and hyphens, include the primary keyword when natural, remove unnecessary stop words, and omit dates unless the article is explicitly time-bound.
4. Do not introduce a promise, result, topic, or claim that does not appear in the approved article.
RETURN EXACTLY
META DESCRIPTION
[One complete description, 160 characters or fewer]
EXCERPT
[Two or three sentences]
SLUG
[lowercase-hyphenated-slug]Show the publish and schedule map
TRIGGER
Event: Author chooses Publish, or the saved Scheduled time arrives
Input: {{blog_post_record_id}}
RUN CONDITIONS
- Working Draft is approved and not empty
- Meta Description, Excerpt, and Website URL Slug are present
- Required CMS destination fields are present
ACTIONS
1. Retrieve the current approved article and reviewed metadata
2. Send the mapped fields to the selected CMS destination
3. Confirm that the CMS created or updated the complete article
4. Save the returned destination post ID when available
5. Save the confirmed public URL to Blog Post URL
6. Save the actual publication date and time
7. Change Status to Published
8. Notify the author that the article is live
SCHEDULED PATH
- Change Status to Scheduled when a future time is selected
- Do not mark the record Published before the CMS confirms it is live
ON FAILURE
- Do not change Status to Published
- Do not erase the approved article or reviewed metadata
- Log the failed step and destination error
- Leave the record available for a manual or automated retryThe article is live at its destination, Blog Post URL and the actual publication time are saved on the parent record, and Status is Published.