> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gradial.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Rework Sections and Reusable Content

> Swap components, restructure sections, update reusable content blocks, and drive changes from a source document — with the impact known before anything changes.

Some changes don't stay where you put them. Swap a component and the section around it has to still work. Edit a reusable content block and it changes on every page that references it — including pages you weren't thinking about and teams you didn't tell. Hand over a marked-up Word doc with fourteen changes in it and someone has to translate each one into a CMS operation.

This is where content work stops being typing and starts being judgment about scope. Gradial does the typing and shows you the scope first: which pages reference the block you're about to change, what the section looks like after the swap, and what the source document actually asked for.

### What this covers

| Change | Examples |
| :- | :- |
| Component swaps | Replacing one component type with another |
| Batched changes | Multiple discrete updates in a single request or ticket |
| Find-and-replace | Text changes across components or a handful of pages |
| Reusable content | Creating or updating content fragments and structured content items |
| Shared page sections | Updating experience fragments and other multi-page blocks |
| Versioning | Creating a new version of an existing page before you change it |
| Document-driven updates | Updating pages from Word docs, decks, PDFs or spreadsheets |

***

## General Workflow

These updates follow an extended version of the standard workflow:

1. **Start a content update task** in Gradial
2. **Define the scope** (single component, multiple components, or fragment)
3. **Provide source material or instructions**
4. **Generate revised content**
5. **Review and refine** across all affected areas
6. **Run QA and validation checks**
7. **Apply updates** in the CMS

***

## Update Type: Component Swaps

### Purpose

Replace an existing component with a different component type while preserving content intent and page structure.

### Common Scenarios

* Swapping a basic text component for a text-with-image component
* Replacing a static banner with an interactive carousel
* Upgrading a legacy component to a newer version
* Changing a CTA style (e.g., button to card)

### How It Works

1. **Select the target page and component** to be replaced
2. **Specify the new component type** to use
3. **Provide mapping guidance** for how existing content should transfer
4. Gradial **generates the new component** with migrated content
5. **Review the swap** to ensure content and layout integrity
6. **Apply the change** via Launch or direct authoring

### Considerations

* Field mappings between old and new components may require manual guidance
* Some content may not have a direct equivalent in the new component
* Visual review is recommended to catch layout shifts

***

## Update Type: Multiple Discrete Changes (Batched Updates)

### Purpose

Execute several unrelated updates across a page or site within a single ticket, improving efficiency for routine maintenance.

### Common Scenarios

* Quarterly compliance updates affecting multiple sections
* Campaign refreshes touching headlines, CTAs, and images
* Post-launch fixes addressing several small issues at once

### How It Works

1. **Create a single task** with multiple update instructions
2. **List each change clearly**, specifying:
   * Target page and component for each
   * The specific update required
3. Gradial **processes each change independently**
4. **Review all changes** in a consolidated view
5. **Apply updates** together or selectively

### Best Practices

* Number or bullet each discrete change for clarity
* Group changes by page when possible
* Indicate priority if some changes are more urgent

***

## Update Type: Find-and-Replace Edits

### Purpose

Make consistent text changes across multiple components or pages in bulk.

### Common Scenarios

* Rebranding (company name, product names, taglines)
* Legal or compliance updates (disclaimer text, terms)
* Date or year updates (© 2024 → © 2025)
* Terminology standardization

### How It Works

1. **Define the search term** (exact text or pattern)
2. **Define the replacement text**
3. **Set the scope** (single page, section, or site-wide)
4. Gradial **identifies all instances** and generates replacements
5. **Review the change list** before applying
6. **Apply changes** in bulk or selectively

### Considerations

* Review matches carefully—context matters
* Some instances may require different handling
* Preserve formatting and links in replaced text

***

## Update Type: Structured Content Items

### Purpose

Create or update reusable, structured content blocks — Content Fragments in AEM, datasource items in Sitecore, entries in Contentful, and the equivalent in each other connected CMS. See [Working with Fragments](/docs/creating-new-experiences/working-with-fragments) for how these map across platforms.

### Create a Content Fragment

1. **Specify the fragment model** to use
2. **Provide the content** for each field in the model
3. Gradial **generates the fragment** according to the schema
4. **Review field mappings** and content accuracy
5. **Create the fragment** in your CMS

### Update a Content Fragment

1. **Select the existing fragment** to modify
2. **Provide update instructions** for specific fields
3. Gradial **generates revised content** for the targeted fields
4. **Review changes** against the original
5. **Apply the update** to the fragment

### Key Benefits

* Fragment updates propagate everywhere the fragment is used
* Structured content ensures consistency
* Changes are versioned and auditable

***

## Update Type: Layout-Based Blocks

### Purpose

Update reusable page sections that bundle layout and components together — Experience Fragments in AEM, Partial Designs in Sitecore, Content Blocks in SFMC, and the equivalent in each other connected CMS. See [Working with Fragments](/docs/creating-new-experiences/working-with-fragments) for how these map across platforms.

### Common Scenarios

* Updating shared headers or footers
* Modifying promotional banners used across pages
* Refreshing navigation elements

### How It Works

1. **Select the experience fragment** to update
2. **Identify the component(s)** within the fragment to modify
3. **Provide update instructions**
4. Gradial **generates the revised fragment content**
5. **Review the changes** in context
6. **Apply the update** to the experience fragment

### Considerations

* Changes affect all pages using the fragment
* Coordinate with stakeholders before updating shared elements
* Test across multiple page contexts

***

## Update Type: Create a Version of a Page

### Purpose

Generate a new version of an existing page—useful for A/B testing, seasonal variations, or campaign-specific messaging.

### Common Scenarios

* Creating a holiday version of a landing page
* Building an A/B test variant
* Developing a region-specific version
* Archiving current state before major updates

### How It Works

1. **Select the source page** to version
2. **Specify what should change** in the new version
3. Gradial **generates the new page version** with modifications
4. **Review the new version** against the original
5. **Save as a new page** or Launch branch

### Best Practices

* Use clear naming conventions for versions
* Document the purpose of each version
* Set expiration or review dates for temporary versions

***

## Update Type: Document-Driven Updates

### Purpose

Update page content using an external source document—Word doc, PowerPoint, or PDF—as the input.

### Update Page from Copy Doc (Word)

**Best for:** Text-heavy updates with structured content

1. **Upload the Word document** containing approved copy
2. **Map document sections** to page components
3. Gradial **extracts and applies content** to the appropriate fields
4. **Review the mapping** and generated content
5. **Apply updates** to the page

### Update Page from PowerPoint

**Best for:** Campaign or creative briefs with visual layout context

1. **Upload the PowerPoint file**
2. **Indicate which slides** correspond to which page sections
3. Gradial **interprets slide content** and maps to components
4. **Review extracted content** and adjust as needed
5. **Apply updates** to the page

### Update Page from PDF

**Best for:** Approved final documents, legal content, or archived materials

1. **Upload the PDF**
2. **Identify the relevant sections** for extraction
3. Gradial **extracts text and structure** from the PDF
4. **Review and refine** the extracted content
5. **Apply updates** to the page

### Tips for Document-Driven Updates

* Use clean, well-structured source documents
* Annotate or highlight sections that map to specific components
* Provide supplementary instructions for ambiguous areas
* PDFs with complex layouts may require additional guidance

***

## Ticketing Integration for Medium Updates

Medium updates work well with ticketing integrations, though they may require:

* **Richer ticket descriptions** with detailed instructions
* **Attached source documents** (for document-driven updates)
* **Defined scope** (pages, components, or fragments affected)
* **Stakeholder review steps** before final application

The same fast-lane benefits apply—reduced handoffs, consistent tracking, and governed execution—with appropriate review gates for the added complexity.

***

## Key Takeaways

* Medium updates involve **more scope or complexity** than simple copy changes
* **Multiple components, fragments, or pages** may be affected
* **Source documents** can drive updates directly
* **Human review remains essential** given the broader impact
* **Versioning and governance** are preserved throughout

***

## When to use this

* Component modernization or upgrades
* Batch maintenance across multiple page areas
* Rebranding or terminology standardization
* Fragment management (content and experience)
* Campaign versioning and A/B testing
* Processing approved documents into web content


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.