Activity logs

What the Activity Log shows

Activity Log is the audit view for important system events. It uses the activity feed to show when something happened, which channel recorded it, what event occurred, what changed, who acted, and which order, sample, branch, or subject may be related.

Use it when investigating unexpected changes, confirming who updated a record, reviewing security events, or understanding recent clinical and operational activity in a branch.

The audit trail focuses on clinical, operational, financial, user, permission, and security changes. Technical housekeeping such as sync cursor updates, queue processing, scheduler heartbeats, cache records, and session maintenance belongs in operational diagnostics and is intentionally excluded from Activity Logs.

Activity Logs are reviewed in Kashef Cloud. Local Kashef records activity while staff work offline and uploads it automatically during sync; Local order, sample, dashboard, and Activity Log surfaces provide a link to the matching Cloud workspace instead of rendering a second audit feed.

Tenant scoping

When a branch is selected, the activity query is scoped to that branch and its lab company. It includes activities with matching branch or lab company properties, order activity for orders in the branch, sample and test result activity connected to branch orders, and user activity for users assigned to the lab company.

This prevents one branch from becoming mixed with unrelated company data while still allowing company-level activity to appear where relevant.

Columns

The table shows one summary row per related operation instead of one row for every database event. For example, creating an order can produce order, item, sample, payment-request, invoice, and notification events; these appear as one Order Created summary with a Related Events count. The Type icon helps you scan the activity category quickly, such as orders, samples, payments, results, inventory, transfers, notifications, automation, or failures. The Origin badge identifies whether the operation happened in Kashef Cloud or Local Kashef. Changed Fields are compact tags: the table shows up to five and then a remaining-count control, while View Details keeps the complete list. The table also shows recorded time, channel, event, actor, and optional branch, order, and sample identifiers.

All visible users and records use their operational display IDs, such as USR-..., ORD-..., and a sample barcode. Internal UUIDs remain hidden. The summary is generated by the activity feed from the most meaningful event in the group, while the detail view preserves every underlying audit row.

Changed-field counts represent unique business fields across the grouped operation. Generated catalog snapshots and synchronization bookkeeping are retained in the immutable underlying audit record but are hidden from the normal comparison; the detail view states how many internal/generated fields were hidden. Requested tests appear as their own related order-item events with reviewable identity, pricing, source, quantity, and comment fields instead of hundreds of catalog internals.

Filters

Use channel and event filters to narrow the type of activity. Use the actor filter to review one staff member's work; each option includes the user's display ID. Use the subject filter for major subjects such as Order, Sample, Test Result, or User. Use recorded-between for a time range. The related-record filter accepts the displayed order ID or sample barcode and resolves it to the internal record automatically.

When investigating a patient complaint or delayed result, start with the order or sample ID if available. Then widen to actor or time range if the related record filter does not show enough context.

View Details modal

The View Details action opens a read-only grouped timeline. Each related event can be expanded to show its origin, actor, timestamp, channel, event, safe context values, and field-level changes with before and after values. Some system events do not contain field-level changes; the modal states this clearly while still showing their context.

Use the modal when the table summary is not enough to understand the full operation. The same grouped detail experience is available from Order Activity, the Sample details slideover, and Recent Activity on the Manager Dashboard. Foreign-key changes and diagnostic context are converted to display IDs before they are shown.

Practical investigation flow

Start with the time of the issue. Filter by order or sample if known. Open relevant rows and compare changed fields. Check actor and channel. If the activity was automation or queue related, look for failed, skipped, or processed events around the same time. If the actor is System, inspect the context and related job or automation information.

Remember that logs explain what the system recorded; they do not replace staff handover. Use notes, order history, sample status, result review records, and finance records alongside the activity log when reconstructing an incident.

Checklist

• Time range matches the suspected incident window.
• Branch context is correct.
• Order ID or sample ID filters are used when available.
• Actor and channel are checked before assigning responsibility.
• View Details is used to review every related event and its recorded changes.
• Findings are documented outside the log when management action is needed.