Configuring Project Identity and Delivery Options

Opening the project settings administrators can change

Before you edit project identity or delivery details in Atloria, make sure you are signed in with access to manage that project’s settings. If you can open the project workspace and see the Settings area, you can usually review the available options there. If the Settings area is missing or you can only view project content without editing controls, you will need a project administrator or someone with higher access to update these values for you.

1. Sign in to Atloria and open the project you want to manage.
2. From the project workspace, go to the project’s Settings area.
3. Look through the settings sections for the fields related to project identity, website presentation, and delivery setup.
4. Compare what belongs to the public-facing site with what is only used for internal project maintenance.

In practice, these settings usually fall into two groups:

• Public presentation settings affect how the project appears to readers, such as the project name, description, and website-facing details.
• Maintenance and delivery settings affect where documentation is delivered and how published output is organized.

If you recently worked through webhook setup, keep that separate from the identity and delivery work covered here. For webhook-specific controls, use Configuring Project Webhooks and Related Controls.

As you review the form, remember that not every saved change appears in the same place at the same time. Some updates show up right away inside the project workspace, especially visible labels such as the project name. Website-facing changes may not appear on the published site until the project is rebuilt, republished, or otherwise refreshed through your normal publishing flow.

Updating the project name, description, and visible identity

The project identity settings in Atloria control how your documentation project is recognized in project lists, headers, and public-facing views. Start by opening the project’s Settings area and locating the fields that define the project’s visible name and summary information.

1. In Settings, find the field used for the project title or name.
2. Replace the existing value with the updated project name.
3. Find the description or summary field and update the text so it matches the project’s current purpose.
4. If the settings form includes branding fields such as a logo or icon, add or replace those assets.
5. Save your changes and review the project header and related listings.

A clear project name matters because Atloria uses it in places where team members identify the project quickly, including workspace headers and project lists. The description helps provide context in discovery-style views and project metadata areas, especially when several projects have similar names.

If branding options are available in the same form, use them carefully. A logo or icon can make the project easier to recognize, but it should stay consistent with the name and description. After saving, check whether the updated identity appears in these places:

• The project header inside the workspace
• Project listings or dashboard views
• Navigation labels tied to the project name
• The generated or published project presentation, if your project has a website view

If the project name changes significantly, review any related labels elsewhere in the settings so the public presentation still feels consistent. A new title with an old description or outdated branding can make the project look unfinished.

Configuring website-facing options for how the project is presented

Website-facing settings control how the project is presented when readers access it through a web view or published documentation site. In Atloria, these options are typically managed from the same project Settings area as the identity fields, so it helps to review them together before publishing changes.

1. Open the project’s Settings area.
2. Locate the website-related section.
3. Review the fields that control whether the project is visible through a website or public view.
4. Update any display labels or website metadata shown in that section.
5. Save the settings and check the published result or preview.

These options matter because they influence how readers discover and understand the project before they even open a page. Depending on what is available in your project settings form, you may see controls related to:

If your project is already published, changes here can affect navigation labels, page titles, and how the project is identified in browser-facing views. If your team manages several documentation sites, consistent website labels are especially important so readers can tell projects apart.

When you update website-facing settings, compare them with the identity details you changed earlier. The visible project name, website label, and description should support the same message. If they do not match, readers may see one name in the workspace and another on the published site, which creates confusion.

For broader website and project presentation settings, you can also refer back to Managing Project Settings and Website Options.

Choosing delivery paths and output locations

Delivery settings determine where Atloria places the generated documentation when the project is published. These values are especially important when your project is available under a specific website path, because the delivery location and the website path need to work together.

1. In the project Settings area, find the fields related to delivery or output location.
2. Review the primary path value used for published documentation.
3. If a base path or destination path is available, confirm it matches your intended publishing structure.
4. Save the changes before testing the published result.
5. Open the project’s published location and verify the pages load where you expect.

A delivery path is not just an internal detail. It affects whether links resolve correctly and whether readers land on the right project section. If your project is published under a specific URL segment, the delivery path should support that same structure. For example, if the website settings point readers to a project-specific location, the delivery settings should not send the output somewhere that uses a different path pattern.

Before you save, check for these common problems:

• A path that duplicates another project’s destination
• A base path that does not match the website-facing publishing location
• A destination that would break existing links
• Small formatting mistakes that create missing pages or incorrect paths

After saving, test the result from the reader’s point of view. Open the published project, move through the main navigation, and confirm that pages open without path errors. If the homepage works but deeper pages fail, the delivery path and website path may not be aligned.

Managing connected controls that affect maintenance and publishing behavior

Identity, website, and delivery settings should be treated as one connected group. In Atloria, changing one of these values often means you should review the others before the next release or republish. This is especially true when a project is already live and readers depend on stable labels and paths.

1. After changing project identity fields, review the website-related settings in the same Settings area.
2. After changing website-facing labels or visibility, check the delivery path fields.
3. If you change the publishing location, confirm the visible project name and website presentation still match.
4. Save the full set of updates, then test the project before your next release.

The most common dependency is between the project’s visible identity and its website location. A renamed project may also need updated website labels. A changed website path may require a matching delivery path. If only one part is updated, the result can be inconsistent: the workspace shows one project identity, while the published site still reflects older naming or older path structure.

For documentation managers, consistency matters across releases. Keep these items aligned:

• Project name and website label
• Description and public-facing summary text
• Branding assets and the current project identity
• Website path and delivery destination
• Visibility settings and the actual published result

This is also a governance issue. If your team publishes multiple versions or maintains several projects, use the same naming and path rules every time. That makes review easier and reduces the chance of broken links or confusing branding during release work. When planning changes that affect publishing behavior, coordinate them with your normal release process instead of updating them in isolation.

Verifying the updated project presentation and delivery setup

After saving your changes, take time to verify both the project workspace and the published result. In Atloria, a settings form can save successfully while the visible website still shows older information until the latest output is available. A quick review helps you catch mismatches before readers do.

1. Return to the project workspace and check the project header.
2. Confirm the updated project name and description appear where expected.
3. If branding assets were changed, verify the logo or icon displays correctly.
4. Open the website or published project view and test the main entry point.
5. Move through a few pages to confirm the delivery path is working correctly.
6. If something looks wrong, go back to Settings and compare the identity, website, and delivery fields side by side.

Focus on what readers will actually see:

• The project title in the workspace and site header
• Description or summary text in visible project areas
• Branding assets in navigation or header areas
• The published path used to reach the project
• Page-to-page navigation after the project loads

Common issues usually fall into a few patterns. A missing logo often means the branding update did not carry through as expected. A correct project name with the wrong published path usually points to a mismatch between website settings and delivery settings. A saved change that does not appear on the site may mean the project still needs to be rebuilt or republished through your usual publishing workflow.

If the public result does not match the form values, reopen the same settings screen and compare each related field carefully rather than changing values at random. Small differences in labels or path settings are often the reason the final presentation looks wrong.

Overview

This section of project settings in Atloria is where project administrators keep the project’s identity and delivery setup aligned. The main goal is to make sure the project looks correct to both internal team members and public readers, while also ensuring the published output appears in the right location.

The work in this area usually includes:

• Updating the project name used in headers and project lists
• Revising the project description or summary text
• Adjusting visible branding such as a logo or icon, if those options are available
• Reviewing website-facing settings that control visibility and presentation
• Confirming delivery or output paths used for published documentation

These settings are closely connected. A project rename can affect website labels. A website path change can affect where documentation should be delivered. A branding update can require a quick review of the published site to make sure the visual identity still matches the current project name and description.

Because this document follows webhook configuration, it does not repeat those controls here. If you need to revisit that setup, use Configuring Project Webhooks and Related Controls.

Use this settings area whenever your team is preparing for a release, refreshing project branding, reorganizing published documentation paths, or correcting how a project appears to readers. The most reliable approach is to review identity fields, website options, and delivery settings together in one pass, then verify the result in the workspace and the published view.

The next step in this sequence is Managing Project Webhooks and Delivery Checks, which focuses on validating delivery behavior after these settings are in place.

Prerequisites

Before you start changing project identity or delivery options in Atloria, make sure these basics are in place:

• You can sign in to Atloria and open the correct project workspace.
• You have access to the project’s Settings area.
• You know which project name, description, branding, and publishing path your team wants to use.
• You are ready to verify the result in both the project workspace and the published project view.
• If the project is already live, you understand that changes to labels or paths may affect what readers see.

It also helps to prepare a few decisions before opening the settings form:

If your team has already been working through project setup, you may also want to confirm earlier configuration choices before editing these fields. For example, website-related decisions from Managing Project Settings and Website Options can affect how you choose delivery values here.

Avoid making identity and path changes without checking how they relate to your current publishing setup. Even when the form is simple, the visible result can span project headers, website labels, and published paths. Preparing those decisions first makes the update much smoother.