Managing Project Creation Choices and Setup Readiness

Preparing the Information You Need Before Creating a Project

Before you open Projects and start a new workspace, make sure you can actually create projects in your Atloria account. If you do not see the project area after signing in, or you can open Projects but do not see a way to start a new one, check with your administrator before you begin. Some setup decisions also depend on organization-level access, especially if your team controls publishing, connected sources, or reporting settings centrally through the admin area.

You should also gather the details that will appear in the project from day one. At minimum, have the project name ready, along with any internal identifier your team uses to distinguish similar products, versions, or documentation sets. Decide who owns the project and who will maintain it after setup. If you plan to connect existing content, collect the source locations you will use during setup so you can choose the right creation path without stopping midway.

Before creation, agree on how authors will work in the new project. In Atloria, this usually means deciding whether the team will start from imported source content, create pages directly in a structured documentation workspace, or combine both approaches. That choice affects how cleanly your project grows later, especially when you begin organizing pages, versions, and reusable content.

It also helps to think one step ahead. If the project will later be published to one or more destinations, tracked in analytics, or organized by audience, language, or category, define those expectations now. Stable naming, consistent metadata, and clear ownership make later setup much easier.

If you need help deciding on a setup approach first, review Planning Project Structure Before Document Authoring.

Choosing the Right Project Creation Path

When you click to create a project in Atloria, the most important early decision is how you want that project to begin. Your team may be able to start with a blank project, use a prepared template, or create the project from existing content sources. Each path leads to a usable project, but they support different kinds of work.

A blank project is usually best when you want full control over the structure from the start. Choose this path if your team already planned the page hierarchy, metadata, and authoring approach and does not want inherited defaults. It gives you a clean starting point, but it also means you will need to define more settings yourself after the project is created.

A template-based project is a better fit when your organization already has preferred structure, naming patterns, metadata expectations, or publishing defaults. Instead of rebuilding those choices manually, the template can give your team a ready-made starting point. This is especially useful when multiple projects need to follow the same documentation model or when consistency matters for reporting and publishing.

Creating a project from existing content is the right choice when your documentation already lives somewhere else and you want Atloria to reflect that source early. This path matters because initial import decisions often shape how content is grouped, how sections are split, and how reusable material is handled later. If the source is organized poorly, that mess can carry forward into authoring and cleanup work.

The tradeoff is speed versus control:

If you expect multiple publishing outputs, audience-specific content, or detailed analytics from the beginning, take the slower path and choose the option that gives you the strongest structure rather than the fastest launch.

Creating the Project and Setting Core Options

1. Sign in to Atloria and open the Projects area from your main workspace. Look for the option to create a new project and open the project creation screen.

2. Enter the project’s main identifying details. Use the project name your team will recognize immediately, and complete any additional identifying fields shown during setup. If Atloria asks where the project should live, choose the correct workspace or organization so the right team can access it after creation.

3. Select how the project will start. Depending on what Atloria shows in your account, this may include a blank project, a template, or an option tied to existing content. After you choose, review any setup panels that appear. These may prompt you to connect a content source, upload material, or accept a starter structure for the new project.

4. Complete the core setup options shown on the screen. Pay close attention to fields that define the project’s default language, content organization, and required metadata. These choices affect how authors create pages later and how consistently content can be filtered, reviewed, and published.

5. Save the project when the required fields are complete. After saving, open the new project and review its initial settings page. In most cases, ownership, some descriptive details, and other administrative settings can still be adjusted later. However, the creation path, imported source shape, and other foundational setup choices may influence parsing, publishing, and analytics in ways that are harder to undo.

Use the first save as a checkpoint, not the finish line. Once the project exists, confirm that the workspace looks right before inviting contributors or importing large amounts of content.

Configuring Decisions That Affect Authoring and Parsing

The setup choices you make when the project is created shape what authors see later when they begin writing and organizing content. If you start with a structured content model, authors will usually work within a clearer page hierarchy and more predictable metadata requirements. If you begin from imported material, the imported structure may influence how topics are divided and how easy they are to edit afterward. A mixed workflow can work well, but only if your team is clear about which content should stay connected to source material and which content should be maintained directly in Atloria.

If your project includes imported content, pay close attention to how source files or folders are mapped during setup. Early mapping decisions affect how content is segmented into pages or sections. A clean source arrangement usually leads to cleaner imported topics, while a confusing source layout can create unnecessary cleanup for writers. The same is true for extraction behavior: if content is brought in too broadly or split too aggressively, authors may spend more time repairing structure than writing.

Naming and categorization choices also matter here. Consistent project naming, topic labels, and metadata defaults make it easier for contributors to find the right content later. They also reduce duplicate pages and inconsistent labels across the workspace. If Atloria shows required metadata during setup, treat those fields seriously. They are often the foundation for filtering, review, and publishing decisions later.

Common setup mistakes that create rework include:

• Choosing a source structure that does not match how the team plans to maintain content
• Leaving required metadata undefined until after authors have already started writing
• Mixing imported and manually authored content without clear ownership rules
• Using inconsistent naming for sections, categories, or content groups

A little extra care during setup saves a lot of cleanup once the project begins to grow.

Setting Up Publishing and Analytics Readiness

Project setup is not only about getting authors into a workspace quickly. It also determines how smoothly the project moves into publishing and how useful the reporting will be later. In Atloria, the way you organize content at creation time affects how easily that content can be grouped, filtered, and delivered through future publishing workflows.

If the project will eventually support more than one publishing output, define the content organization carefully from the start. Clear section names, stable categories, and consistent metadata help you prepare content for different destinations without reorganizing everything later. If your team plans to publish for different audiences, products, or release tracks, those distinctions should be reflected in the project structure and metadata choices early.

Analytics readiness depends on the same discipline. Reporting works best when the project has a stable identity and consistent categorization. If teams create similar projects with inconsistent names or apply labels differently across content, reporting becomes fragmented. That makes it harder to compare usage, activity, or performance across projects. For that reason, define project-level metadata and categorization fields early, especially if your team expects to review analytics by product line, documentation area, or audience.

Not every publishing or reporting option has to be completed during the first creation screen. Use this rule of thumb:

• Configure foundational items during creation:
  • Project name
  • Ownership context
  • Default language
  • Core content organization
  • Required metadata and categories
• Configure follow-up items after the project is saved:
  • Detailed publishing destinations
  • Additional project administration settings
  • Analytics review screens and later reporting checks

If you want to explore those project-level areas after setup, see Managing Project Settings and Website Options, Configuring Project Webhooks and Related Controls, and Analyzing Project Performance and Activity.

Verifying Your Setup Before Authors Start Working

1. Open the new project and go through its settings and setup-related screens carefully. Confirm that the project was created in the correct workspace, that the selected creation path matches your original plan, and that any connected content source appears where expected.

2. Review ownership and administrative details. Make sure the right people can access the project and that the project is assigned to the correct team context. If your organization separates project administration from authoring, confirm those assignments before content work begins.

3. Check the metadata and structure defaults inside the project. Look for the categories, required fields, language settings, and content organization choices you expected to see. If those defaults are missing or inconsistent, fix them before contributors begin creating pages.

4. Run a small test using representative content. Create a sample page or import a small amount of source material instead of loading everything at once. Then review the result. Confirm that content is split sensibly, required fields appear where they should, and the project’s publishing-related options align with the structure you chose.

5. Validate reporting consistency. If the project will be measured in analytics later, confirm that the identifying fields, categories, and taxonomy values appear consistently across the sample content. This helps prevent reporting from splitting similar content into separate groups.

6. Resolve readiness issues before launch. The most common problems are missing permissions, incorrect source mapping, incomplete metadata requirements, and publishing-related options that are not yet available in the project.

A short verification pass at this stage is much easier than correcting a live project after several authors have already started building content.

Overview

This guide focuses on the decisions that happen between planning and active content work in Atloria. By this stage, you should already have a rough structure in mind from Planning Project Structure Before Document Authoring. The goal here is to turn that plan into a project setup that supports the way your team will actually write, import, organize, publish, and measure documentation.

The most important idea is that project creation is not just an administrative step. The choices you make on the New Project screen and in the project’s early settings influence several later workflows at once. The selected creation path affects whether the team starts from a blank workspace, a predefined structure, or existing content. Core setup fields influence how pages are grouped and how contributors enter metadata. Early source decisions affect how imported material is divided and maintained. Those same choices also shape how easily the project can be published and how cleanly it appears in analytics.

This guide walks through four practical areas:

• What information to gather before opening Projects
• How to choose the right project creation path
• Which core options to set during creation
• How to verify setup readiness before authors begin working

Use this guide when you are preparing a new documentation workspace and want to avoid cleanup later. It is especially useful for project administrators, documentation managers, and team leads who need the project to support both authoring and downstream workflows from the start.

Prerequisites

Before working through this setup process in Atloria, make sure the following are already in place:

• You can sign in successfully and reach the main authenticated workspace
• You can open the Projects area
• You have permission to create a new project, or you know who can create it for you
• You know which workspace or organization the project belongs to
• You have already reviewed Creating Projects and Completing Onboarding if your team is still new to the initial project flow
• You have already compared setup styles in Choosing Between Manual and Connected Project Setup if you are unsure whether to start from connected content or a more manual structure
• You have already planned the broad content shape in Planning Project Structure Before Document Authoring

It also helps to have this information ready before you start:

• The project name and any internal naming standard your team follows
• The person or team who will own the project
• The content source you plan to use, if the project will begin from existing material
• The preferred authoring approach for the first release
• Any required language, category, audience, or reporting expectations

After your project is created and verified, continue with Managing Project Structure and Content Planning to refine the workspace for day-to-day authoring.