Quick Start

A hands-on walkthrough to get your first module running — from platform prerequisites through creating your first issue.

This guide walks you through setting up Maecos from scratch — creating the platform building blocks, configuring an issue category, and seeing the full cycle from issue creation to resolution. No theory, just hands-on steps.

By the end, you'll have a working Issues & Logbook module and understand the configuration patterns that apply to every module in the platform.

Who is this for? Administrators or superusers setting up Maecos for the first time. You need admin access to your Maecos tenant (https://[your-tenant].maecos.com).

Step 1: Platform building blocks

Every module depends on a shared set of building blocks. Setting these up correctly now saves you from restructuring later. These are configured once and reused across all modules.

1

Verify your admin access

Log into your Maecos tenant. Navigate to Settings. If you can see the full Settings menu, you have admin permissions. If not, ask your tenant administrator to assign you the required permissions.

2

Create at least one equipment item

Navigate to Settings › Organization › Equipment. Create your first equipment item — this represents a production line, machine, or work area. Name it something meaningful (e.g. "Packaging Line 1" or "Mixing Area A").

Equipment is the foundation — it's referenced in downtimes, checklists, documents, and issues. You'll create more later, but one is enough to start.

Think about your equipment hierarchy before creating many items. A common pattern is Site → Area → Line → Machine. Start with one or two items to learn the configuration; restructure before you add the full plant.

3

Create at least one workstation

Navigate to Settings › Organization › Workstations. Create a workstation linked to your equipment. Workstations represent the physical or logical locations where operators interact with the platform.

For more on workstation behavior, see Workstations.

4

Create test users

Navigate to Settings › Users and Access Management › Users. Create at least two test users:

1. A superuser — with full admin permissions (this might be your own account)

2. A test operator — with limited permissions, representing a frontline user

This lets you verify that your configuration works correctly from both perspectives.

5

(optional) Create labels

Navigate to Settings › Organization › Labels. Labels are cross-cutting tags applied across modules — to documents, issues, checklists, and more. They enable filtering that cuts across your category structure (e.g. product family, regulatory standard, shift). You don't need these on day one, but plan your taxonomy early — labels multiply fast without governance.

6

(optional) Review notification settings

Navigate to Settings › Communication › Notifications. Each module has its own notification triggers (issue assigned, document approved, checklist overdue). Start conservative — enable only critical triggers at launch. Too many notifications trains users to ignore them.

Readiness check before continuing: At least one equipment item exists. Workstations are created and linked. User accounts exist for admin and test users. Your browser is a modern Chromium-based browser or Firefox. If all of this is in place, you're ready for your first module.

Step 2: Configure your first issue category

The Issues & Logbook module is the best place to start — it's the most commonly used module and demonstrates the configuration patterns shared across the platform.

1

Create an issue category

Navigate to Settings › Issues › Categories. Click Create category and set up a basic category:

• Name: "Quality" (or whatever fits your first use case)

• Subcategories: Add 2–3 subcategories (e.g. "Non-conformance," "Customer complaint," "Quality alert")

• Workflow: Start with the default workflow — you can customize later

Categories define how issues are organized, who can see them, and what workflow they follow. Every issue belongs to a category.

2

Assign issue permissions

Navigate to Settings › Users and Access Management. Assign the following permissions to your test users:

• Test operator: Permission > Issues > Can create issues + Can view team issues

• Superuser: All issue permissions

Permissions control what users can do. Categories control what they can see. Together, they create your access model.

3

Configure notifications (optional but recommended)

Navigate to Settings › Communication › Notifications. Activate the triggers for issue creation and assignment. This ensures your test operator gets notified when an issue is assigned to them.

Step 3: Create your first issue

Now test what you've configured.

1

Log in as the test operator

Open a different browser or use incognito mode. Log in as your test operator account. You should see the Issues icon in the navigation.

2

Create an issue

Click + Issue. Select the category you configured. Fill in the mandatory fields — title, subcategory, description. Add any relevant context (equipment, workstation, photos). Submit the issue.

3

Switch to the superuser view

Log back in as the superuser. Navigate to Issues. You should see the issue created by the test operator. Open it — verify the category, fields, and workflow status are correct.

4

Walk through the workflow

Assign the issue to yourself. Change the status through the workflow steps. Add an action. Close the issue. This validates the full lifecycle: creation → assignment → investigation → resolution.

Step 4: Verify and reflect

You now have a working Issues & Logbook configuration. Before expanding, check these items:

• Can the operator find and create issues? If not, check permissions and category visibility.

• Does the workflow make sense? If steps feel unnecessary, simplify the workflow before you roll out to more categories.

• Do notifications work? If the operator didn't receive a notification on assignment, check Settings › Communication › Notifications.

• Can the operator see only what they should? Log in as the operator and verify they don't see categories or issues beyond their scope.

What you've learned applies everywhere. Every module in Maecos follows the same pattern: configure the structure in Settings → assign permissions → test from the operator's perspective → validate before rollout. The specific settings differ per module, but the approach is the same.

Ready for the next module? Start with General Principles for a deeper understanding of Issues, or jump to any module's Step Approach to begin configuration.

What to configure next

Once you're comfortable with Issues, the natural next steps depend on your priorities:

If you want to...	Start with...	Why
Track production stops and OEE	Downtimes General Principles	Connects stop events to issue investigations
Execute standard work on the floor	Checklists General Principles	Builds on equipment and workstation setup
Manage SOPs and procedures	Documents General Principles	Creates the link between documents and checklists
Track operator skills and training	Skills & Training General Principles	Enables skill-based permissions across all modules
Run structured performance meetings	Meetings General Principles	Most valuable once issues and actions exist

Don't try to configure everything at once. The most successful rollouts start with one module on one line, validate it with real users, then expand. The modules are designed to be adopted incrementally — each one adds value independently and becomes more powerful when connected.