Follow these rules while you build the app to avoid fixes that cost far more later. Rules marked Fails silently give no error. The app builds and runs, but the defect only appears in the customer's output, or not at all.
One app, one workflow
- Don't build one app to handle multiple workflows. One app per workflow instead, if two paths share only the intake page, they're two apps, and splitting later costs more than starting split.
- Don't design the flow as you build it. Map pages and their triggers before opening PatternBuilder, apps built on the fly accumulate workarounds that are expensive to unpick.
- Don't bury the deciding question deep in the flow. Ask high-selectivity questions first, "Is this a litigation matter?" belongs on page one or two, before anything it governs gets built out.
- Don't loop over a fixed, known count, or ship a loop with no guaranteed exit. Reserve loops for genuinely variable counts and test the exit, a loop again with no tested termination makes the app unusable, not just slow.
Data tables
- Don't create one giant table to hold everything. One table per real-world entity instead, clients, matters, attorneys. If you can't name the table after something the customer would recognize, it's the wrong table.
- Don't create more tables than you need. Stop splitting when a table stops describing something nameable, fewer, well-keyed tables beat an elegant schema nobody can query.
- Don't leave unused tables behind. Fails silently, nothing validates a table the app never references, so a missing key column sits there unreported. Keep only what the app actually uses.
- Don't upload a CSV whose columns don't match the table. Fails silently, a casing difference or swapped column order lands data in the wrong place without complaint. Export the empty table first, then fill that file.
- Don't default a row selector to the value the user sees. Fails silently, PatternBuilder matches on the key column, so a default holding the displayed value selects nothing. Set the default to the row's key value instead.
Repository & service accounts
- Don't hand over an app whose service account is only half set up. Every condition has to hold, work the whole checklist, then watch one row process end to end: (1) a dedicated account with internal full admin rights, (2) a group created specifically for it, granted PatternBuilder permissions, (3) in the cabinet, VESA rights plus Edit Multiple Document Profiles Simultaneously plus cabinet admin.
- Don't put the service account in the Users or Builders groups. Keep it in its own group instead, so its rights can be audited without touching anyone's access.
- Don't hand off an app still in test mode, or activate it before QA is finished. Stay in test mode through QA, then activate as the deliberate last step of go-live.
- Don't assume table references survived the import. Import the background app first, then wire the foreground to the real IDs, PatternBuilder mints new internal IDs on every import.
