Objects
Associations & ERD
Model links between objects, static objects, child records, and the ERD view.
Associations & ERD
Associations & ERD covers relationships between dynamic objects, static models, child records, notes, files, tasks, tickets, bookings, assets, and linked data. Use this page when you are setting up the product surface, reviewing a rollout, or troubleshooting why users see a different result from an administrator.
What this surface is
- Primary purpose: relationships between dynamic objects, static models, child records, notes, files, tasks, tickets, bookings, assets, and linked data.
- Where users start: Object relationship settings live under
/settings/objects/:objectId/object-settings; ERD view uses/settings/objects/:objectId/erd-view. - Where administrators configure it: Record detail pages show related panes such as linked records, notes, attachments, tasks, tickets, and object renderers.
- Runtime/detail surface: Associations make object data navigable, reportable, and usable in pages, workflows, and API queries.
- Platform connections: Associations connect lookup fields, child objects, static panes, pages, reports, workflows, and portal exposure.
Where it lives
| Area | Path or surface | Use it for |
|---|---|---|
| User surface | Object relationship settings live under /settings/objects/:objectId/object-settings; ERD view uses /settings/objects/:objectId/erd-view. | Day-to-day work and review. |
| Configuration | Record detail pages show related panes such as linked records, notes, attachments, tasks, tickets, and object renderers. | Setup, permissions, routing, labels, and behaviour. |
| Runtime/detail | Associations make object data navigable, reportable, and usable in pages, workflows, and API queries. | Testing the live experience users actually see. |
Configure it
- Confirm the audience for this surface and whether they are staff users, portal users, customers, public visitors, or administrators.
- Open the owning product route: Object relationship settings live under
/settings/objects/:objectId/object-settings; ERD view uses/settings/objects/:objectId/erd-view. - Review the configuration route and permissions before changing live behaviour: Record detail pages show related panes such as linked records, notes, attachments, tasks, tickets, and object renderers.
- Define the primary records, fields, statuses, owners, and notifications involved in this workflow.
- Configure Lookup association, Child object, and Static pane first because they shape the rest of the rollout.
- Add Hierarchy and ERD only after the core path works with sample data.
- Test the runtime surface as a restricted user, not only as a superadmin: Associations make object data navigable, reportable, and usable in pages, workflows, and API queries.
- Check downstream connections after saving: Associations connect lookup fields, child objects, static panes, pages, reports, workflows, and portal exposure.
- Record the owner, rollout date, and support path for the configuration.
- Review the first week of activity and remove any option that users do not understand or need.
Configuration options
| Option | Use when | Notes |
|---|---|---|
| Lookup association | One record references another | Use for customer, asset, project, or location links. |
| Child object | A parent owns many related records | Use for line items, inspections, applications, or activities. |
| Static pane | Notes, files, tasks, or tickets should attach to a record | Enable the relevant object setting. |
| Hierarchy | Records need parent/child structure | Model carefully and test filters. |
| ERD | Builders need a relationship map | Route: /settings/objects/:objectId/erd-view. |
| Linked records | Operators need context on detail pages | Configure view panes and renderers. |
Operating notes
- Keep labels aligned with the words users see in the product, especially Lookup association and Child object.
- Permissions still matter even when a menu, page, or link is visible.
- If users see empty data, check role filters, enabled apps, ownership rules, and saved filters before editing records.
- If a change affects customers or public visitors, test from a logged-out or customer account as appropriate.
- Use reports or logs to confirm the change produced the expected operational result.
- Capture configuration decisions in rollout notes so support teams know what changed.
- Do not reuse one option for unrelated processes just because it is already configured.
- Review linked notifications, workflows, dashboards, and reports after changing this surface.
- Prefer narrow changes that can be tested with sample data before a tenant-wide rollout.
- When troubleshooting, start at the route users open, then inspect configuration, permissions, and logs in that order.
- Keep retired settings hidden or archived so users do not choose outdated paths.
- Assign an owner for ongoing review; unattended configuration becomes stale quickly.
For developers
Use these pages when the surface is read or changed by code, scripts, embeds, widgets, API clients, webhooks, or realtime listeners.
- /developer/data-hooks
- /reference/objects-records
- /reference/field-selection
- /reference/filters-and-queries