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 pagefollows a defined process.

Why configuration is beingspecial

written.

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:

It

aren't willrecorded cover:in the configuration source, so they can be lost in a rebuild or upgrade, and drift between Sandbox and Production.

The sandbox-first process

for

changingDescribe fields,the layouts,change — what field/layout/record type, on which record, and recordwhy. types,Make and what's safe to change directlyit in the interface.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.