Build your app's report tree — folders, friendly names, sub-folders

Folders past 20 fields become hard to scan. Users scroll, miss things, and rebuild reports because they didn't realize the right field existed. When a folder approaches that size, look for natural sub-groups and break them out as sub-folders.

The split above keeps each level readable. A user who wants ticket dates knows exactly where to look; a user who wants customer info isn't wading through ticket fields to find it.

Primary keys and foreign keys are the plumbing of joins, not data users want in reports. Same for audit columns (created_by, updated_at, row_version) — they're useful for debugging schema issues, not for business reporting. Leave them out unless someone has a specific reason. If you exposed them and now want them gone, edit the field and delete it from the folder; the column is still in the underlying table for joins, just not visible to Composers.

If a sensitive field is in the database, your only real defense against it appearing in a report is not adding it to the Report Tree. Database grants are a backstop, not the primary control: as long as the integration's account can SELECT the column, an App Builder can pull it in.

Practical hardening: keep a written list of "do not expose" fields per category. Audit the Report Tree against the list before you grant the app to users. For really sensitive data, consider a database view that simply doesn't include the field — defense in depth. Row-level security (covered in Module 4) restricts which rows users see; the Report Tree is what restricts which columns.

If multiple people are App Builders, agree on conventions early. Casing — all lowercase, Title Case, Sentence case — pick one. Abbreviations — spelled out ("Identifier") or abbreviated ("ID"). Date suffixes — "on" (Opened on) vs. "date" (Open date). None of these is right or wrong; consistency is what matters.

An app where half the fields are customer name and half are Customer ID looks unfinished, even if functionally everything works. A short style guide pinned somewhere shared (a doc, a wiki) saves hours of "should this match that?" debates later.

If your database view aliased a single source table twice (covered in Build your first app — the contact-table-as-customer-and-partner pattern), the report tree needs to show that disambiguation, or your users will get confused datasets.

The pattern: build separate folders for each role of the aliased table. Example with cust_contact and part_contact — create a Customer Contact folder pulling from the cust_contact alias, and a Partner Contact folder pulling from the part_contact alias. Same source table, two different aliases, two different folders.

Then rename every field that shows up in both. If both folders have a column called name, exposing both with the display name Name means a Composer building a report sees two columns called Name and has to remember which folder each came from. Rename to Customer Name and Partner Name. Same for email, phone, address — anything that's likely to show up in the same report alongside its sibling.

Two columns from the same row of result data sharing a header is the trap. Disambiguating at the display-name level prevents it without your users having to think about it.

Don't declare a category done because the Report Tree looks right in App Builder. Open Composer, pick fields from across folders and tables, and confirm: previews load, names look correct, data types make sense, no surprise SQL errors. Issues found here are usually 30-second fixes; the same issues found by users a week later mean rebuilding reports.

Sometimes two tables genuinely belong in the same category but have no valid join — the canonical example is finance, with a balance sheet and an income statement that share no key. The video walks the recommended pattern: put the un-joinable tables in separate folders (e.g., Income Statement and Balance Sheet), and educate users that fields shouldn't be combined across those folders. The folder boundary becomes a visual cue.

This works because Composers building reports tend to stay within one folder unless they have a specific reason to span. The folder structure plus a one-line note in the app description is usually enough. If your audience doesn't read app descriptions and you can't tolerate cross-folder mistakes, the alternative is splitting into separate categories — sometimes separate apps.

What to avoid: putting fields from un-joinable tables in the same folder. That guarantees SQL errors when users combine them, with no visual hint that they're forbidden combinations.

Moving fields one at a time is fine for a few; tedious for a folder full. The Report Tree supports bulk operations. In any folder's field list, the column header has a checkbox — clicking it selects every field in the folder. You can also click individual row checkboxes to select a specific subset.

Once you have a selection, two icons appear next to the column-header checkbox: a stacked left/right arrow (the move action) and a trashcan (bulk delete). Move opens a folder picker — pick the destination, confirm, done. The selected fields land in the new folder in the same order; everything else stays put.

Use this whenever you've outgrown a folder's size (the 20-field rule above), spun up a new subfolder for grouping (Calculations, Date Parts, Identifiers), or are reorganizing post-import. The formula-fields lesson will produce a lot of new fields; bulk-move is how you tidy up afterward.

Heavy report-tree work — restructuring folders, mass renames, re-organizing for a new audience — benefits from a clone of the category as a known-good fallback. The clone option lives on the action menu of each category. Tiny safety net, occasionally saves a half-day of "what did I change again?"