# Plan an Editorial Calendar with Scheduling and Approvals

> Source: https://agilitycms.com/docs/editors/plan-an-editorial-calendar

An editorial calendar is the plan for what goes live, and when. Most teams keep the calendar itself wherever they already plan work, such as a spreadsheet or a project tool. Agility is where that plan gets carried out: tasks give each piece an owner and a due date, approvals make sure it has been reviewed, and scheduling releases it at the right moment without anyone staying up to press **Publish**.

This article shows how to connect the two, so the dates in your calendar are the dates content actually goes live.

## Plan backwards from the go-live date

For every entry on the calendar, work out four dates, counting back from when it should appear:

| Date | What must be true | Agility feature |
| --- | --- | --- |
| **Draft by** | The content is written and saved, and the writer has checked it in Preview. | Staging, Preview |
| **Approve by** | A reviewer has approved it. Leave time for one round of changes. | [Approvals and Workflows](/docs/editors/workflows) |
| **Schedule by** | The release (and, if needed, the expiry) is set. | [Scheduling Overview](/docs/editors/scheduling) |
| **Go live** | The scheduled release publishes it. | Scheduling |

Putting all four on the calendar turns "the launch is on the 14th" into a set of deadlines people can act on.

## Step 1: Turn calendar entries into tasks

Create a task in Agility for each piece of work, so the owner sees it where they work.

1. Open the **Tasks** tab in the Notifications panel and create a task.
2. Give it a **Title**, choose who it is for in **Assign To**, and describe the work in **Details**.
3. Set the **Due Date** to the *draft by* date, not the go-live date.
4. Set the **URL** to the page or item the work is on.

See [Task Management](/docs/editors/task-management). For a launch with many pieces, one task per piece is easier to track than one large task.

## Step 2: Build review time into the plan

If the pages and content lists you're working on require approval, nothing goes live until a reviewer has approved it. Plan for that:

- **Give reviewers a window, not a deadline on the go-live day.** An approval requested an hour before release leaves no room to fix anything that's declined.
- **Review nested content too.** Since September 23, 2026, publishing a page or content item also publishes its nested linked content by default, including saved changes in that nested content. If only the item itself should go live, the person publishing can tick **Publish this item only** in the Publish prompt (it appears only when there is nested content to include).
- **Check what's waiting.** The **Ready to Publish** report lists items that are approved, awaiting approval, or in Staging and ready to publish. It's a quick way to see what's still outstanding before a release. See [Accessing Reports](/docs/owners-admins/accessing-reports).

To turn on approvals for a page or content list, see [Approvals and Workflows](/docs/editors/workflows).

## Step 3: Schedule the release

Scheduling sets a **Release Date** (when the content publishes itself) and, optionally, an **Expiry Date** (when it unpublishes itself). You can schedule content items, pages and components. See [Scheduling Overview](/docs/editors/scheduling) for the steps.

Things to plan around:

- **The live version stays live until the release.** If you schedule an update to something already published, the current version stays on your site until the release date passes. If the old version must come down sooner, unpublish it first.
- **Use expiry dates for anything time-limited.** Campaign banners, offers and event promotions should come down by themselves. Put the expiry date on the calendar too.
- **Pages can redirect while they wait.** When you schedule a page, you can set a **Redirect URL** to send visitors elsewhere before the release (or after the expiry).
- **Temporary changes can revert automatically.** Publish the temporary version now, then make the change back and schedule it for when the temporary period ends. Scheduling Overview calls this stacking a change.
- **Check time zones.** Dates and times in Agility are shown in the time zone you've chosen for your account, and each person chooses their own. When a release must happen at a set local time, confirm everyone involved reads the same time. See [Set your timezone and display language](/docs/editors/timezones).
- **Allow for a short delay.** Because of caching, scheduled content can take a few minutes to appear on (or disappear from) your site. If a release must happen to the minute, talk to your developer.
- **Check nested content before you schedule,** as well as the item itself.

## Step 4: Release related changes together

Some releases are a set: a new product page, its listing card, and a homepage banner that points to it. If they go live at different times, visitors can hit a broken link or an empty page.

- **Schedule them for the same time,** so the whole set appears together.
- **Or publish them together now.** [Batch Content Publishing](/docs/editors/batch-content-publishing) lets you select several items or pages and publish them in one action. Batch publishing publishes now; for a set time, use scheduling.
- **Check the result.** Batch publishing processes each item with your own permissions, so an item you aren't allowed to publish fails while the others go ahead. When the task finishes, check that everything you expected was published.

## Step 5: Review the calendar every week

Once a week, compare the plan with what actually happened:

- **Recent Changes** shows what was modified, and by whom, filtered by date, sitemap, user and locale.
- **Ready to Publish** shows what is approved or waiting.
- Both reports can be exported, which is handy for updating a calendar kept in a spreadsheet. See [Work Faster in Agility](/docs/editors/work-faster-in-agility).

Move anything that slipped, and look for patterns: if approvals are always the bottleneck, widen the review window or add a reviewer.

## Example: a product launch on a Thursday at 9:00

| When | What | Who |
| --- | --- | --- |
| Two weeks before | Calendar entry created; tasks assigned for the product page, listing card, banner and blog post | Content lead |
| Monday the week before | Drafts saved and checked in Preview | Writers |
| Wednesday the week before | Approvals requested | Writers |
| Friday the week before | Approved, including nested content | Reviewer |
| Monday of launch week | All four items scheduled for Thursday 9:00; banner given an expiry date four weeks later | Publisher |
| Thursday 9:15 | Live site checked; Recent Changes reviewed | Content lead |

## Related articles

- [Scheduling Overview](/docs/editors/scheduling)
- [Approvals and Workflows](/docs/editors/workflows)
- [Batch Content Publishing](/docs/editors/batch-content-publishing)
- [Task Management](/docs/editors/task-management)
- [A Content Operations Playbook](/docs/editors/content-operations-playbook)