Data Layouts

A data layout describes how a single record is displayed — which fields appear, in what order, grouped how, with which read-only vs editable controls. Different audiences need different layouts of the same data: a sales rep, a support agent and a finance person all see the same customer record but care about different parts.

What a Layout Defines

• Field order: Sequence in which fields appear.
• Grouping: Sections with headings (e.g. “Contact”, “Billing”, “Notes”).
• Visibility: Which fields show; which are hidden in this layout.
• Editability: Read-only vs editable per field per layout.
• Related panels: Embedded lists of related records (e.g. customer's orders).
• Tabs: Different layout pages within the same record.
• Layout-specific actions: Buttons available in this layout but not others.

Per-Audience Layouts

One record, many views. Common patterns:

• Internal admin layout: Everything visible, everything editable.
• Internal staff layout: Most fields visible, some restricted to admins.
• Customer-facing layout: Only the customer's own data, minimal editing.
• Read-only audit layout: Everything visible, nothing editable.
• Mobile-optimised layout: Single column, most-important fields first.

Worked Examples

• CRM customer record: Sales view shows pipeline; Support view shows tickets; Finance view shows billing — all of the same record.
• Patient record: Doctor view shows clinical history; Receptionist view shows demographics + appointments; Billing view shows insurance + invoices.
• Product record: Editor view has all fields editable; Public marketplace view shows only the listing fields.
• Mobile field service: Engineer's mobile layout strips out admin fields and pulls in job-specific actions.

This article walks through creating a new data layout from scratch, starting with the default and customising for a specific audience.

Step-by-Step

1. Open Architect Panel → Datastores → (your datastore) → Layouts.
2. Click New Layout.
3. Name it (e.g. “Sales rep view”) and pick a base — start from default or duplicate an existing layout.
4. In the canvas, drag fields into sections. Create new sections with the “+” button.
5. Configure each field's properties:
   • Label override.
   • Read-only / editable.
   • Conditional visibility (show only if X).
   • Help text.
   • Column width (1, 2 or full-width).
6. Add tabs for related panels (e.g. an Orders tab inside a Customer layout).
7. Save and assign to the relevant security groups.
8. Preview as a member of that group to verify.

Layout Best Practices

• Most important first: Put fields the user looks at most at the top.
• Group related fields: Address fields together, billing fields together.
• Wide-screen vs mobile: Test both — single column may need its own layout.
• Keep editable fields in distinct sections: So users know where they can change values.

Worked Examples

• Service desk agent layout: Customer name and account-status badge at the top; below that ticket history; at the bottom the long-form notes section.
• Finance reconciliation layout: Billing fields editable; everything else read-only; an Invoices tab shows the full history.
• Customer self-service layout: Profile fields editable; payment methods linked but managed by Stripe-hosted page; no admin fields visible.
• Mobile field engineer layout: Job summary, location with map, customer phone with tap-to-call, current job status — vertical scrolling layout.

Layouts can be tied to security groups, individuals, or made “public” so any user can pick them. Choosing the right sharing model keeps the layout library manageable.

Sharing Models

• Per-group default: Layout used automatically for every user in that group. Most common — sales reps all get the sales layout.
• Per-group available: Members of the group can pick this layout from a dropdown, but the default may be something else.
• Personal: One specific user's customisation; nobody else can use it.
• Public: Available to any user regardless of group.

Default Resolution

When a user opens a record, the platform looks up which layout to use:

1. User's manually-pinned layout (from their own “Set as default” action).
2. Personal layouts assigned to this user.
3. Default for the user's primary security group.
4. Platform-wide fallback default.

Worked Examples

• Multi-team CRM: Sales group default = Sales view; Support group default = Support view; Finance group default = Finance view. Users in multiple groups can switch between them.
• Personal customisation: One particularly visual sales rep creates a personal layout with extra charts; only she sees it.
• Mobile layouts: A “Mobile” layout marked public; any user accessing from a small screen gets it automatically (via device detection).
• Compliance audit view: A read-only “Audit” layout marked public, available to auditors when investigation is in progress.

Tip: Don't proliferate layouts. Each new one is something to maintain. Aim for a small handful (3-5) of well-designed layouts rather than dozens of slight variations.