Configuration

A configuration page shows the specific settings, values, and options for a configuration-intensive feature, so a reader can copy the right setup for their use case rather than follow a procedure. Also known as use cases, configurations are reference pages, not instructions. The tone is plain, descriptive, and straightforward.

Write a configuration when a feature is configuration-intensive, such as rules, and readers mainly need to know which settings and values produce a given outcome. It is not:

• A how-to. A how-to walks through the steps to complete a task, whereas a configuration only shows the settings and values for a setup, with no procedural steps.
• A tutorial. A tutorial teaches through a guided project, whereas a configuration is a reference the reader consults for the right values, not a lesson.
• A reference. A reference exhaustively documents every parameter, whereas a configuration curates example setups for common use cases.

For the full comparison, refer to Content types.

• Title: noun-based, naming the feature being configured, because a configuration describes ways to set up a feature rather than guiding the reader toward a goal.
• Description: name the product or feature configured, the use case it serves, and the key settings or values covered.

Copy this skeleton and adapt it to your feature:

---
title: <Feature> configuration
description: Configure <product or feature> for <use case>, covering <the key settings and values>.
pcx_content_type: configuration
sidebar:
  order: 10
products:
  - product-a
---

Introduce the feature in two or three sentences, frame which configurations the reader will encounter, and link to related documentation.

## <Feature area>

State the outcome this configuration produces, then give the settings and values in a table.

| Setting        | Value                      | Notes            |
| -------------- | -------------------------- | ---------------- |
| <setting name> | <value to enter or select> | <when to use it> |

• Tables are the signature: a reference table with a 1:1 correspondence between each setting the reader can change and the value to enter or select for a given use case.
• Navigation helps readers find the right configuration when a feature has many.
• What does not fit: step-by-step procedures. If you find yourself writing instructions, use a how-to, tutorial, or example instead.

pcx_content_type: configuration
products:
  - product-a
  - product-b

For more details, refer to pcx_content_type.

Open each configuration with a short context paragraph after the title that introduces the feature, frames which configurations the reader will encounter, and links to related documentation. Group the body by feature, giving each feature its own settings table so the reader can scan to the setup that matches their use case.

• Complete setting-value pairs. Give every table row an explicit setting and the exact value to enter or select, because an agent applies the pair directly with no room to infer.
• Use-case framing. State the outcome each configuration produces in its context, so a reader or agent can match a goal to the right table without reading a procedure.
• Instructions point outward. Link to the how-to, tutorial, or example that carries any steps, because a configuration itself is not executable as a procedure.