Making Configuration Changes
Two kinds of change
- Data — adding records, fixing values, importing. Everyday work; see Chapter 4 — Managing Data.
- Configuration / structure — new fields, changed layouts, new record types, dropdown options, validation, relationships. This follows a defined process.
Why configuration is special
The CBM CRM's structure is defined as versioned configuration files and applied with CBM's implementation tooling, so the system can be rebuilt or moved reliably and every change is tracked. If you hand-edit structure directly in Production (via Entity Manager or Layout Manager), those changes:
- aren't recorded in the configuration source, so they can be lost in a rebuild or upgrade, and
- drift between Sandbox and Production.
The sandbox-first process
- Describe the change — what field/layout/record type, on which record, and why.
- Make it in the Sandbox first (via the configuration files / implementation tool) and verify it.
- Review with whoever requested it.
- Apply to Production the same way, once confirmed.
This is the golden rule in its most important form. Structural changes affect everyone at once and are the easiest way to break things — never make them straight in Production.
Safe to do in the interface
- Adding and editing records (data) — Chapter 4.
- Settings, the Tab List, dashboards, labels — System Settings & the Navigation Menu.
- Users, roles, teams — Chapter 2.
Goes through the process (don't do casually in Production)
- New or changed fields
- New record types / entities
- Dropdown options, validation rules, relationships between records
Who to involve
Configuration changes are made with the implementation tooling and, where needed, the CBM implementation team. If you're unsure whether something is "just data" or "configuration," treat it as configuration and check — see Getting Help and Next Steps.