Record pages, trash, and activity

agaro uses a consistent record surface for operational data. A contact, invoice, task, employee, product, campaign, and many other records open in a card that keeps the primary action visible and places related information beside the form.

#Create a record

Open the relevant module and select its primary New action. The create card normally contains:

1. A breadcrumb back to the list.
2. A clear Create action at the top of the card.
3. Sections that group related fields.
4. Required field markers and inline validation.
5. An empty activity area reserved for the record history after creation.

The Create action remains unavailable until the minimum required information is present. Server validation may still reject a value that is incorrectly formatted, outside a permitted date range, or inconsistent with another field.

#Edit an existing record

Existing records use the same surface for reading and editing. Editable fields can be changed in place. The primary action changes to Save when the page has unsaved changes.

If the record is in a locked business state, only permitted fields and actions remain available. Examples include a sent marketing campaign, a posted finance document, or a published social post. Use the record's purpose built transition actions instead of trying to overwrite a protected state.

#Related actions and smart links

Record pages can show related destinations such as payments on an invoice, orders for an event, or participants in an automation. These links preserve the record context and remain subject to the same module and role checks as direct navigation.

#Activity and audit history

Where a record supports activity history, the side rail shows recorded business events such as creation, updates, state changes, and other auditable actions. Workspace settings also have a dedicated recent configuration history under Settings → Security → Settings Audit.

An activity row records the acting user and workspace context. Assistant and API actions use the same authorization path as the web application, so their resulting business changes are attributed to the bound or signed in actor rather than an anonymous system identity.

Not every pointer movement or page visit is an audit event. Treat the activity rail as a history of recorded product actions, not as a complete screen recording.

#The Activity Log page

Open Activity Log in the System group of the sidebar, or go to /activity. It has two tabs: Audit log, the history of actions across the workspace, and Notifications, your own task assignments, overdue alerts, follow ups, and workspace events with a count of what is unread. People without access to the whole workspace see their own actions and the tasks assigned to them.

The Audit log tab offers:

• A summary of Events today (with how many happened yesterday), Last 7 days, People active, and Records changed. When you pick a date range, the summary shows Events in range instead.
• Filters: a search box, Person, Record type, and a date range with presets for Today, Yesterday, Last 7 days, Last 30 days, and This month, or custom dates. Clear filters returns to everything.
• Two views, Timeline and Table. The timeline groups entries by day under sticky day headers, and each entry shows who did what, a link to the record while it still exists and you can reach it, the record type, and a relative time with the exact time on hover or focus. The table lists the activity, entity, action, who, and when.
• Export CSV for the entries you have filtered.

The log shows the latest 500 entries, 100 at a time with Show more. To see older activity, narrow by person or date. Each entry is labeled with what happened, such as Created, Updated, Deleted, Shared, Locked, Restored, Duplicated, Imported, Exported, or Viewed.

#Delete and restore

Many business modules use soft deletion. Selecting Delete or Remove moves the record out of the active list and into Recently deleted instead of immediately erasing it. Open the module's trash view to restore it when that destination is available.

Restoring a record returns it to the active list without creating a duplicate. Related links remain attached because the original record is restored.

Some security sensitive data uses permanent deletion by design. For example, deleting your own assistant conversation removes that conversation and its messages rather than keeping a hidden transcript. Read the confirmation text before approving a destructive action.

#Record access

Being able to open a module does not automatically grant access to every record in it. Access can also depend on:

If a direct record link returns a forbidden or not found page, do not assume the record was deleted. Ask an administrator to confirm both module access and record scope.

See Record scope and field masking for the exact supported areas and release status. A permission configured for one data area must not be assumed to cover all other module records.

#Unsaved changes

Create and edit surfaces warn before abandoning a dirty form where that protection is supported. A dashboard customization draft also stays separate from the saved dashboard until you select Save. Read discard confirmations carefully because they remove only the local draft, not the last saved record.

#Troubleshooting

#Save is disabled

Confirm that a field has actually changed and all required fields have values. Some forms also require at least one line item or a valid date relationship before Save becomes available.

#Save returns read only workspace

Your subscription or billing state currently allows reads but blocks mutations. A billing administrator can restore access from Settings → Subscription.

#The record vanished after deletion

Open the module's Recently deleted view. If the module does not expose trash, contact an administrator before recreating the record because a duplicate may split related history.

#I cannot edit a field

The record may be locked by status, your role may be read only, or a model or field rule may deny the change. Check the status and ask a workspace administrator to review Access Rights.