First Class Modules

Record activity

Shows a paged, filterable, chronological activity timeline for an authorized record with actor, event type/state, date range, relations, and favorite state.

Runtime key
module.record-activity
Experience
Timeline & history
Security
Server-enforced

Use Record Activity to give users an understandable operational history of what happened around a record without exposing raw database auditing or internal event payloads.

Note

The bundled renderer key is module.record-activity. First-class means BuildWithHQ supplies a native, typed, secured runtime experience inside normal app provisioning and the signed-in user's existing permissions.

What it does

Shows a paged, filterable, chronological activity timeline for an authorized record with actor, event type/state, date range, relations, and favorite state.

Key capabilities

  • Search visible records across modules and select a record timeline.
  • Filter activity by event type and date range.
  • Group events chronologically with summary, actor, state, and occurrence time.
  • Page bounded history and show secured relation/favorite context.

Common uses

  • Customer, project, work-order, case, and asset timelines.
  • Operational handoffs and investigation context.
  • A user-facing history adjacent to formal compliance/audit evidence.

How it connects

Activity aggregates the reviewed events emitted by native and dynamic records. Formal security/compliance evidence remains in its audit contracts; the activity module provides the bounded business-facing view.

Where applicable, its records use the universal RecordId conventions so they can participate in secured relationships, activity history, favorites, dynamic fields, notifications, Inbox attention, and global search without copying the source record.

Security and data boundary

The selected record must pass normal scope checks, and only safe activity summaries/metadata are rendered. Private event detail payloads stay outside the browser surface.

  • The authenticated service derives the SaaS app, tenant account, user, DataRole, and location scope; browser identifiers are never authorization proof.
  • The page editor composes React components with validated data bindings. Those bindings call typed runtime APIs, whose application services execute reviewed stored procedures.
  • List, search, detail, relation, activity, favorite, and write operations reapply their required server-side permissions.

Add it to an app

  1. Open the SaaS app in the Developer Console and identify the user journey and page where this module belongs.
  2. Add the validated module.record-activity module block through the supported page/template authoring flow.
  3. Configure the module with the page editor's React components and validated data bindings; the bindings call authenticated platform APIs backed by reviewed stored procedures.
  4. Place the page in the correct user-type menus and assign existing DataRole, record, field, and location permissions.
  5. Test list, detail, search, empty, denied, stale-update, and cross-location behavior before publishing an exact version.
Tip

Write concise activity summaries when workflows change important state. Users should understand the event without needing internal JSON or database knowledge.

Important

A renderer being bundled in the tenant application does not make its data visible in every app. The server returns only components and records authorized for the current app and signed-in user; unavailable or unauthorized blocks fail closed.