Planning Project Structure and Content Governance

Defining the project workspace before adding content

Before your team creates pages, use the project setup screens in Atloria to lock down the basic decisions that affect navigation, publishing, and ownership. This is where you make sure the project name, workspace identity, and access direction are stable enough that writers are not building on top of moving targets. If you still need help with the broader project setup flow, see Managing Project Settings and Website Options.

1. Open your project, then go to the project settings area where you manage the project name, URL settings, and language options. Set the Project Name exactly as you want teams to recognize it across project lists, dashboards, and internal navigation.

2. Review the project’s URL slug or published path setting. Choose a short, durable naming pattern and avoid changing it later unless you are intentionally restructuring published documentation. This helps keep links, navigation paths, and shared references consistent.

3. Set the project’s default language or locale in the language setting used for the workspace. Pick the primary language your team will use for page titles, navigation labels, and published content so new content starts from the correct default.

4. In the audience or access-related settings for the project, decide whether the documentation is meant for internal teams, external readers, or a mix of both. This choice should match how you plan to publish and who should see the content.

5. Decide how the project will be organized before any pages are created. Choose whether you are building:

   • one shared knowledge base,
   • several major content sections inside one project, or
   • a versioned documentation set with separate releases.

6. Open the members, users, or permissions area for the project and confirm who will manage structure decisions, who will coordinate documentation work, and who will write content. Make sure the people responsible for approvals and publishing already have the right access before the first draft is created.

A clear workspace definition prevents later cleanup. It also makes the rest of your governance rules much easier to enforce.

Designing the navigation and content boundaries

Once the workspace basics are set, plan the content map your team will follow. In Atloria, this means thinking about the sidebar, parent pages, section landing pages, and how readers will move between guides, reference material, and release information. The goal is to make the structure obvious before writers begin adding pages in different styles or locations.

1. Start by listing the top-level sections you expect to show in project navigation. Common examples in Atloria projects include product guides, setup instructions, API documentation, release notes, policy content, and troubleshooting. Keep the top level broad enough for readers to scan quickly.

2. In the navigation structure or page tree, decide which items should be section containers and which should be actual reading pages. Use parent pages or landing pages for broad topics, and place detailed task or reference pages underneath them.

3. Set a rule for what belongs inside this project and what should be split into a separate project. Use practical boundaries such as:

   • a different audience,
   • a separate product line,
   • a different publishing schedule,
   • or content that should not be visible to the same readers.

4. Create naming rules for sections and pages. For example, use section names for broad categories and action-based page titles for task content. This keeps the sidebar readable and helps search results make sense.

5. Plan how shared topics will be linked. If a page applies to several sections, choose one main location for it and link to it from related pages instead of copying the same content into multiple places.

6. Decide how related articles should connect across the project. If your team uses cross-links heavily, agree on when to link to onboarding, integration, or policy pages so readers can move between sections without losing context.

If you are also working through webhook and delivery planning, keep that material aligned with the structure decisions here rather than rebuilding it in multiple places. For those controls, refer back to Managing Project Webhooks and Delivery Checks.

A strong boundary plan keeps the project from becoming a catch-all workspace that is hard to navigate and harder to maintain.

Assigning ownership and review responsibilities

A well-structured project still breaks down if nobody knows who owns each section. In Atloria, ownership should be visible in the project’s member access, review flow, and page management habits. You do not need a complicated process, but you do need clear responsibility for drafting, reviewing, and publishing.

1. Divide the project into major sections such as onboarding, product guides, integrations, compliance, or release notes. For each section, assign one primary owner who is responsible for keeping that area accurate and current.

2. Open the project’s access or permissions area and confirm who can create drafts, who can review changes, and who can publish updates. These responsibilities should match how your team actually works, not just job titles.

3. Decide how page-level ownership will be recorded. If your team uses an owner field, review assignment, or internal tracking note, make sure every important page has a named person attached to it rather than a shared team label only.

4. Set expectations for review timing. For example, decide which pages need regular review dates and which pages only need review when a release changes. This helps prevent “evergreen” pages from becoming outdated without anyone noticing.

5. Define what happens when a page no longer has an active owner. Your team should know whether the section owner, project lead, or an administrator takes over when content becomes unowned or stale.

6. Clarify how different contributors participate in the workflow:

   • Writers create and update drafts.
   • Subject matter experts check technical accuracy.
   • Editors improve clarity and consistency.
   • Approvers or publishing leads decide when updates are ready to go live.

7. If your team uses formal review and approval steps in Atloria, align those steps with the people above so there is no confusion about who gives final sign-off.

For a deeper walkthrough of review decisions and publishing readiness, use the version and approval guides linked throughout the Project Settings and version management documentation set.

Ownership works best when it is simple, visible, and tied to actual screens your team already uses.

Setting rules for versions, audiences, and publishing

This is where governance becomes visible to readers. In Atloria, version settings, audience targeting, and publish state decisions shape what people can see and when they can see it. If these rules are unclear, teams often publish the right content to the wrong readers or leave important updates hidden in draft.

1. Decide whether this project will use versioned documentation. If it will, define which releases should appear in the version selector, such as v1, v2, or Latest. Only create version entries that readers will actually need to switch between.

2. Set a rule for what belongs in a versioned release versus what stays outside versioning. For example, release-specific setup instructions may belong in a version, while company policy or support contact process pages may stay unversioned if they apply everywhere.

3. Review audience settings for the project and decide which pages are:

   • internal only,
   • visible to customers,
   • or limited to a specific audience group.

4. Match those audience decisions to your content structure. If an entire section is internal, keep it grouped clearly so writers do not accidentally mix internal-only pages into customer-facing navigation.

5. Define how your team will use content states. Agree on what Draft, Scheduled, and Published mean in practice. For example:

   • Draft for work in progress,
   • Scheduled for approved content waiting on a release date,
   • Published for content that should appear in live output.

6. Confirm where the project will be published. Depending on your setup in Atloria, this may be a public documentation site, a help center experience, or a private documentation area. Your publishing destination should match both the audience settings and the navigation plan.

7. Before finalizing these rules, preview a few likely reader journeys. Make sure a customer sees customer content, an internal user sees internal material, and version switching does not expose the wrong pages.

If you need the detailed setup steps for webhook-related delivery controls, use Configuring Project Webhooks and Related Controls instead of repeating those checks here.

These rules should be written once and reused often so every release follows the same visibility pattern.

Creating governance rules writers can follow consistently

Good governance only works if writers can apply it without guessing. In Atloria, that means turning your planning decisions into repeatable page standards: what metadata to fill in, how to name pages, when to use templates, and how to avoid duplicate content across sections.

Start by defining the fields every page should include. A simple standard is easier to enforce than a long checklist, so focus on the items that directly affect search, ownership, and publishing.

After that, standardize templates for the page types your team creates most often. Task guides should follow one structure, overview pages another, release notes another, and reference pages another. When writers open a new page, they should already know whether they are creating a landing page, a how-to page, or a reference page.

Also agree on rules for reused content. If the same explanation appears in several places, choose one canonical page or shared content source and link back to it rather than maintaining multiple copies. This is especially important for setup instructions, policy language, and recurring product definitions.

Finally, document naming conventions for:

• page titles,
• sidebar labels,
• section names,
• and URL paths.

Use predictable wording so readers can scan the sidebar and know what to expect. For example, action pages should start with verbs, while category pages should describe a topic area.

When writers follow the same rules on every page, review becomes faster and the published project feels consistent.

Verifying the project setup before teams start publishing

Before your team begins publishing regularly, run a final check inside Atloria using real pages, real permissions, and real preview behavior. This step turns your planning rules into a practical test. If something is unclear now, it will become a larger problem once dozens of pages and multiple contributors are involved.

1. Open the project sidebar or content tree and compare it to the structure you planned. Check that top-level sections, parent pages, child pages, and landing pages appear in the right order and use the correct names.

2. Open a sample section and review whether the page layout matches your intended boundaries. Make sure onboarding content, product guides, release notes, and other major areas are not mixed together in ways that will confuse readers.

3. Go to the project’s members or permissions area and confirm access with actual user roles. Verify that writers can create drafts, reviewers can review and approve changes, and publishing rights are limited to the people you selected.

4. Test version behavior by opening content in the project and checking the version selector. Confirm that only the intended releases appear and that pages are assigned to the correct version where applicable.

5. Test audience visibility by previewing content from the perspective of different reader types if that option is available in your workflow. Confirm that internal-only pages stay hidden from customer-facing views and that customer-visible pages appear where expected.

6. Open a sample page in the editor and review its metadata. Check the Title, Description, ownership details, audience setting, version assignment, and current publish state. This is the fastest way to see whether your governance rules are being followed in practice.

7. Publish or preview a small set of representative pages and review the result as a reader would. Look for broken structure, unclear labels, misplaced pages, or visibility mistakes before the full team starts contributing.

A short verification pass at the start saves a great deal of cleanup later, especially once versions and audience-specific content begin to grow.

Overview

• This guide focuses on planning decisions you should make before large-scale content creation begins in Atloria.
• It covers how to define the project workspace, organize the sidebar and section boundaries, assign ownership, and set rules for versions, audiences, and publishing.
• It also explains how to create repeatable governance standards for page metadata, templates, naming, and reused content.
• The final section helps you verify that your structure, permissions, and visibility settings work correctly before your team starts publishing regularly.
• This guide is intended to complement earlier Project Settings documents rather than repeat them:
  • For project-level setup and website options, see Managing Project Settings and Website Options
  • For webhook setup, see Configuring Project Webhooks and Related Controls
  • For delivery checks, see Managing Project Webhooks and Delivery Checks

Prerequisites

• You should already have access to a project workspace in Atloria.
• You should be able to open project settings, the page tree or sidebar structure, and the project’s member or permissions area.
• If your team uses versioned documentation, audience targeting, or controlled publishing, those features should already be part of your project plan.
• Gather the people who will make governance decisions before you begin, such as:
  • the project owner,
  • documentation leads,
  • reviewers or approvers,
  • and the people responsible for publishing.
• It helps to complete the earlier setup guides first so the project’s core settings are already in place:
  • Managing Project Settings and Website Options
  • Configuring Project Webhooks and Related Controls
  • Managing Project Webhooks and Delivery Checks

With those pieces in place, you can use this guide to turn a basic project into a documentation workspace your team can manage consistently over time.