First Class Modules
Record relations
Explores authorized records as a bounded relationship graph and supports typed relation creation/removal only when both endpoints are editable.
module.record-graphUse Record Relations to show how people, companies, work, files, conversations, events, and custom records connect without duplicating those records into a separate graph store.
The bundled renderer key is module.record-graph. 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
Explores authorized records as a bounded relationship graph and supports typed relation creation/removal only when both endpoints are editable.
Key capabilities
- Search visible seed records across modules.
- Traverse secured relationships through bounded depth levels.
- Show nodes, typed edges, module, location, status, activity counts, and favorites.
- Add or remove a typed relation only when both record endpoints and the relation operation are authorized.
Common uses
- Customer/account 360-degree context.
- Case, project, asset, and work dependency exploration.
- Impact analysis and relationship-first CRM experiences.
How it connects
The graph is a view over canonical Records and RecordRelations. Opening a node returns to the appropriate native or dynamic module; the graph does not become a competing source of record data.
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
Every traversed node is independently checked for SaaS, tenant, DataRole, record, and location visibility. Inaccessible nodes and edges are omitted, and mutation requires edit authority on both endpoints.
- 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
- Open the SaaS app in the Developer Console and identify the user journey and page where this module belongs.
- Add the validated
module.record-graphmodule block through the supported page/template authoring flow. - 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.
- Place the page in the correct user-type menus and assign existing DataRole, record, field, and location permissions.
- Test list, detail, search, empty, denied, stale-update, and cross-location behavior before publishing an exact version.
Keep relation types meaningful and limited. A consistent typed relationship vocabulary produces better navigation, automation, and AI context than many near-duplicate labels.
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.