Managing Project Administration from the Project Home

Opening the project home and identifying administrator tools

If you already know how to move around Atloria’s project list from Working with Project Lists and Dashboards, the next step is opening a specific project and using its home area as your control center. From the project selector or project list, choose the project you want to manage. Atloria opens that project inside the main workspace, where the project home becomes the starting point for administrative work and documentation work.

At the top of the project home, look for the project header. This area typically gives you the project name and the main navigation options available inside that project. From here, administrators use the project home to move into the areas that matter most for setup and oversight:

• Onboarding
• Project settings
• Analytics
• Versions
• Audit records
• Technical documentation tools

These areas serve different purposes. Onboarding helps you finish setup tasks. Project settings is where you maintain project details and access-related controls. Analytics helps you review usage and performance trends. Versions lets you inspect release organization and current documentation status. Audit records shows a history of important changes. Technical documentation tools let you continue into the documentation side of the same project without switching context.

Not every person who can open a project will have the same level of control. A project administrator usually handles setup, access, and governance decisions. A documentation manager may work in the same project home but focus more on versions, documentation structure, and publishing-related tasks. When both roles use the same project, the project home helps them stay aligned because they are working from the same project context, even if they use different tabs and actions.

Use the project home whenever you need to confirm project readiness, review change history, or move from administration into documentation maintenance without losing your place.

Completing onboarding tasks from the project home

The Onboarding area is the first stop when a project is new or when major setup changes need to be reviewed. Open the project home, then select Onboarding to see the setup progress for that project. Atloria uses this area to show the tasks that still need attention before the project is fully ready for ongoing documentation work.

Inside onboarding, look for checklist-style items or progress indicators that show what has already been completed and what is still incomplete. These items help you verify whether the project has the basic information and controls needed for a stable documentation workflow. Administrators should use this area to confirm setup work such as:

1. Reviewing the project’s core details
2. Confirming access-related setup
3. Checking documentation readiness before active use

The project home also helps you spot incomplete work without opening every section one by one. If onboarding is not finished, status indicators on the home area make that visible at a glance. This is useful when you are responsible for several projects and need to quickly identify which ones still need administrative attention.

Revisit onboarding when the project changes in a meaningful way. Common examples include:

• A change in project ownership
• A new team or environment being added
• A shift in how documentation is created, reviewed, or published
• A restart of setup after earlier work was left incomplete

Onboarding is not only for first-time setup. It is also a practical review tool when a project’s structure or responsibilities change. If documentation managers report that publishing, version work, or technical documentation tasks are blocked, checking onboarding can help you confirm whether the project still meets the required setup expectations.

When the onboarding area shows that all required items are complete, you can move into settings, versions, and documentation work with more confidence that the project foundation is in place.

Updating project settings and access-related configuration

From the project home, open Project settings whenever you need to update the project’s administrative details. This area is where you review the configuration categories available for that project and make changes that affect how the project is managed in Atloria.

Start by checking the core project information shown in settings. This is the best place to confirm that the project details still match how the team is using the project. When you update project information in settings, those changes are reflected back in the project home, helping everyone see the current project identity and status from the main workspace.

Project administrators should also review any project-level controls related to access and membership. Depending on what is available in your project, this can include:

• Who can enter the project
• Which team members can manage project configuration
• Which users are limited to documentation work
• Other project-level controls tied to access or oversight

These changes should be made carefully because they affect who can work inside the project and what they can do once they are there. If you are adjusting permissions or member access, confirm the impact before saving so you do not accidentally remove access needed for version work, reviews, or publishing preparation.

Some settings updates should be coordinated with documentation managers. In particular, talk through changes that could affect:

• Documentation structure
• Version workflows
• Publishing readiness
• Technical documentation maintenance
• Team responsibilities inside the project

For example, if you change project access or reorganize who manages the project, documentation managers may need to adjust review steps or confirm that the right people still have access to versions and documentation tools. Use the project home after saving changes to verify that the project still presents the expected navigation and that the team can continue working without interruption.

If you need broader administrative guidance beyond a single project, see Managing Organization and Admin Settings and Managing User Access and Administrative Permissions.

Reviewing analytics and version activity from the home area

The project home gives administrators a quick path into both Analytics and Versions, which are often reviewed together. Open Analytics from the project home when you want to understand how the project is performing from a usage and activity standpoint. In Atloria, the analytics area is labeled Analytics & Insights and is intended for usage statistics and performance metrics.

If the analytics area is available but not yet active in your workspace, you may see a coming-soon style message rather than detailed charts. Even so, the project home still treats analytics as a dedicated administrative area, and it remains the place you will return to when usage reporting is available for your project.

Next, move into Versions from the same project home to review release history and the current state of your documentation versions. This is where administrators and documentation managers can inspect whether a version is current, in progress, or no longer the main release being used by readers.

Analytics and versions are most useful when you compare them together:

1. Open Versions to identify the version you believe is active.
2. Open Analytics to review whether that version is actually being used as expected.
3. Compare recent publishing activity with usage patterns before making release decisions.

This review pattern helps with practical decisions such as:

• Checking whether a newly published update is being adopted
• Deciding whether an older version can be archived
• Confirming whether a low-usage version still needs to remain available
• Reviewing whether documentation activity matches release expectations

If you are preparing to make changes to version organization, review the version workspace first, then use analytics to support the decision rather than relying on assumptions. For deeper version guidance, continue with Managing Documentation Versions Across the Release Cycle and Analyzing Project Performance and Activity.

Using audit records to track administrative changes

When something changes in a project and you need to know what happened, open Audit records from the project home. This area is for tracing actions, not measuring usage. It helps administrators review the history of important project events and understand who made a change, when it happened, and what part of the project was affected.

In the audit view, review each entry for the key details that help with investigation:

Use audit records to review administrative events such as:

• Changes to project settings
• Access or membership updates
• Version-related actions
• Other documentation-related administrative changes

This is especially helpful when a project starts behaving differently than expected. For example, if a team member reports that access changed, a version status looks different, or a project setting no longer matches prior decisions, the audit trail helps you verify whether the change was intentional and who made it.

Audit records are different from analytics. Choose Audit records when you need accountability and change tracing. Choose Analytics when you need usage trends or performance patterns. If you are trying to answer “Who changed this?” or “When did this start?”, use audit records first. If you are trying to answer “Are people using this?” or “Did activity increase after release?”, use analytics instead.

For broader audit and security review practices, see Reviewing Security and Audit Controls and Managing Audit Exports and Activity Records.

Working with technical documentation tools from the project home

The project home is not only for administration. It also acts as the bridge into the project’s documentation work. From the same project context, you can move from setup and oversight into technical documentation tools without going back to the project list or switching to another workspace first.

This matters most for documentation managers and project administrators who work closely together. A documentation manager may begin on the project home to confirm the project’s current state, then move into version work or technical documentation views. An administrator may start in settings or audit records, then open the documentation side of the project to confirm that the project is ready for editing, review, or publishing-related work.

Common handoffs from administration into documentation work include:

1. Checking Project settings before editing or publishing documentation
2. Opening Versions to confirm the correct release structure
3. Moving into technical documentation tools to continue content work in the same project
4. Returning to Audit records if a documentation-related change needs to be traced

This workflow is useful because it keeps governance tasks and documentation tasks connected. Instead of treating project administration and technical documentation as separate activities, Atloria lets you manage both from the project home. That makes it easier to confirm readiness before work begins and easier to investigate problems if something changes later.

Use the project home as your central workspace whenever you need to balance project configuration with documentation maintenance. Start there to confirm the project is correctly set up, move into versions to check release structure, and then continue into the technical documentation area for the actual content work. The next document, Exploring Technical Documentation Inside a Project, walks through that documentation side in more detail.

Overview

Use the project home in Atloria as the main entry point for project administration. It brings together the areas administrators and documentation managers use most often, including Onboarding, Project settings, Analytics, Versions, Audit records, and the project’s technical documentation tools. Instead of opening separate workspaces for each task, you can stay inside one project and move directly to the area you need.

The project home is especially useful when you need to combine governance work with day-to-day documentation support. For example, you might open onboarding to confirm setup progress, move to settings to adjust project details, check versions to review release status, and then open technical documentation tools to continue content work. If something looks wrong after a change, audit records help you trace what happened.

Keep these points in mind:

• Use Onboarding to track setup completion and revisit project readiness after major changes.
• Use Project settings for project details and access-related configuration.
• Use Analytics to review usage and performance trends when available.
• Use Versions to inspect release organization and current documentation status.
• Use Audit records to investigate who changed something and when.
• Use the project home as the handoff point between administrative work and documentation maintenance.

If you need help getting back to the right project before starting, return to Working with Project Lists and Dashboards.

Prerequisites

Before you manage a project from the project home, make sure you can open the project and that your role includes the areas you need to use. Some people may be able to view a project but not change settings or review administrative records.

You should have:

• Access to sign in to Atloria
• Permission to open the target project
• A role that allows project administration, or a documentation management role if you are handling versions and documentation tasks
• A project that already exists in the project list or project selector

It also helps if you already know how to:

• Open a project from the project list
• Recognize the main dashboard and project navigation
• Switch between project areas without losing your place

If you have not done that yet, read Working with Project Lists and Dashboards first.

You may also want the right people available before making changes in the project home:

• A project administrator for settings and access decisions
• A documentation manager for version and content coordination
• Team members who can confirm whether a change affects publishing or documentation workflows

If you cannot see Project settings, Analytics, Audit records, or other project home options mentioned in this guide, your current role may not include those areas. In that case, ask a project administrator or organization administrator to confirm your access. If you are still getting into Atloria for the first time, start with Accessing and Registering Your Atloria Account or Signing In to Atloria and Solving Access Problems.