Product map

Moltaro is organized around one product model: configured record types create runtime records, users work with those records, and modules add process, attention, entitlement, automation, reporting, and governance around the same data.

Use this map to choose where to read next.

Records are the center

Data and records explains the objects people work with day to day. A record is one instance of a configured record type, such as a request, asset, contact, inspection, production item, warranty case, or other business object.

Records can have fields, related records, comments, files, tags, activity, and history. They can also appear in process surfaces such as Boards or become part of entitlement, reporting, automation, and access workflows.

Data structure defines the model

Data structure is where configurators shape the system. A record type is configured through an entity definition: its fields, relationships, display behavior, access model, audit behavior, runtime screens, and UI surfaces.

This area is for people who decide what the system should know about the operation. Everyday users do not need to understand every configuration detail, but they benefit from the model because it controls what appears on lists, forms, detail pages, selectors, and reports.

Working with records is the daily workflow

Working with records covers the repeated patterns users see across Moltaro: list pages, search, filters, detail pages, create and edit dialogs, related data, import/export, and responsibility.

The exact fields and actions change by record type, but the shape is familiar: find the right records, open the detail, make an allowed change, follow related context, and trust that access and audit rules still apply.

Boards add governed process

Boards add process state around records. A board item can carry status, responsibility, due date, links, comments, attachments, movement history, and cycle context while the underlying record remains the source of truth for the business object.

Boards are useful when work needs to move through stages, handoffs, queues, or responsible teams without creating disconnected copies of the same record.

Entitlement Operations governs rights

Entitlement Operations is a module for rights to use, receive, access, or claim something. It supports concepts such as models, plans, parties, beneficiaries, resources, limits, periods, renewal, issued terms, and ledger activity.

It is useful when a team needs to answer questions such as who may use a license, membership, service, warranty, information resource, or customer-owned resource, and needs the answer to remain auditable.

Work Inbox turns changes into attention

The Work Inbox is the in-app place for notifications and active attention signals. Notifications describe events or changes. Attention signals describe current operational facts that need action, such as due-soon, overdue, blocked, missing-owner, or responsibility-driven work when a module provides those signals.

Inbox items link back to the related record, board item, entitlement, or other resource with access checked again when the user opens it.

Automation and business logic add behavior

Automation and business logic explains behavior that goes beyond manual editing: field behavior, statements, presentation rules, validation, before-save changes, actions, triggers, schedules, and run history.

For technical implementation, continue into Business logic and Developer documentation. Moltaro supports C# business logic through workspace-specific operational logic and reusable package runtime extensions.

Access and governance keep work explainable

Access and governance covers roles, permissions, entity access models, assignments, field access, delegated access, and audit trail concepts.

Moltaro separates broad capability from concrete responsibility. A role can give a user permission to perform a kind of action, while a record assignment can explain why that user is responsible for one specific item.

Operations and developer areas support the installation

On-premise operations is for deployment, updates, backups, monitoring, maintenance, and troubleshooting. It matters when the runtime and operational data need to stay inside a controlled environment.

Developer documentation is for SDKs, packages, integrations, APIs, and technical extension points. Most users do not need it, but it is important when configuration alone is not enough.