Skip to content

Navigation, search, lists, and detail pages

Moltaro screens vary by record type and module, but the common pattern is consistent: choose an area, find the right work, open the object, review its context, take an allowed action, and follow related work when needed.

Navigation is organized around product areas and configured runtime pages. Some areas are always part of the core product, such as records, roles, users, audit, and configuration. Other areas appear when their module is enabled, such as Boards, Entitlement Operations, Work Inbox, Booking, or Currency Rates.

The same business object may be reachable from more than one place. For example, a record can appear in a record list, be opened from a board item, be linked from an inbox item, or be referenced by an activity entry. Moltaro re-checks access when the object is opened.

List pages are for scanning and narrowing a set of records or items. A list usually shows the identifying fields, status or responsibility context, and the columns that matter for that record type or module.

Use a list when you need to:

  • browse records of one type;
  • sort or filter operational data;
  • select records for a bulk or contextual action;
  • open a detail page or preview drawer;
  • move from a high-level result to the underlying record.

The fields on a list come from configuration. If two record types show different columns, filters, or labels, that usually means their entity definitions or UI surfaces were configured differently.

Search helps you find work by text or configured query behavior. Filters narrow the list by fields, status, responsibility, date, module context, or other available criteria.

Not every field is searchable or filterable. Configuration can hide fields from search, restrict sorting, or define which fields appear in list and filter surfaces. Access rules can also affect which records or field values a user is allowed to see.

Saved views and quick filters, when available on a surface, are shortcuts for recurring questions such as “my open work”, “overdue items”, or “records in a specific state”.

A detail page is the main place to understand one record, item, entitlement, role, user, or other resource.

Detail pages commonly include:

  • the display name and summary facts;
  • field values and configured sections;
  • related records or module context;
  • comments, files, tags, or activity when supported;
  • permitted actions such as edit, archive, move, assign, export, or run an operation;
  • audit or history context when enabled and allowed.

The detail page should be treated as the source of context for one object. If a list tells you that something exists, the detail page explains what it is, why it is in its current state, and what you can do next.

Actions are commands users can intentionally run from a record, list, board item, or module surface. Some actions are simple, such as opening, editing, or archiving. Others can run configured business logic, move work through a board, issue an entitlement, or update responsibility.

Available actions depend on permissions, record state, field rules, module rules, and configuration. If an action is missing or blocked, the usual reason is that the user is not allowed to perform it, the object is in the wrong state, or required information is missing.

Moltaro keeps work connected. A record can have related records, comments, files, tags, board context, entitlement context, activity entries, and audit history. Related content helps users understand the whole work object without copying information into separate trackers.

Activity and audit are related but not identical. Activity helps people follow what happened around the work. Audit is the governed evidence of important changes and actions.

The Work Inbox helps users start from what needs attention instead of browsing every list manually. Notifications point to events or changes. Attention signals point to current operational facts that need action.

When you open work from the inbox, Moltaro opens the related object through the same resource and access model as any other route. The inbox is a starting point, not a bypass around permissions.

  • Start from the area that matches your question: records for business objects, boards for process state, entitlements for rights and usage, and the inbox for personal attention.
  • Use search for known text and filters for structured questions.
  • Open the detail page before making changes that affect ownership, status, access, or history.
  • Check related content before creating a duplicate record.
  • Treat missing fields, missing actions, and hidden records as possible access or configuration effects, not only as missing data.