How no-code works (objects, fields and metadata)
Why you can adapt the CRM on your own, without programming, and how to think about that flexibility.
In many systems, changing a record type requires a programmer and a new release. Not here. Objects, fields and values are treated as configuration. When you create or change a field, the system starts displaying it, validating it and including it in forms, lists, the board and exports automatically.
What this means in practice
- Need to store companies' tax IDs? Create a "Tax ID" field and it shows up instantly.
- Does your funnel have different stages? Edit the Stage field's values to match your own phases.
- Want a new object, like "Contracts" or "Properties"? Model it as a custom object.
- Team changed? Create a new access role and define what it sees, object by object.
How to approach modeling
- List the "cards" your business uses (objects).
- For each card, list the data you need to store (fields).
- Identify the choice fields (lists) and their values (e.g. Stage, Status, Industry).
- Define who accesses what (roles).
Dependent lists: one list's options change with another
A picklist can depend on another picklist of the same object. Example: in Type you choose "Product" or "Service", and Subtype only shows the options that make sense for that choice. To set it up, open the child field in Settings → Objects and fields, pick the parent list under "Depends on" and, in the table that appears, check for each parent option which child options stay available. A parent option with nothing checked keeps the full list.
The dependent list only appears on the form after the parent list has a chosen option; until then it stays hidden.
On the record form, changing the parent option filters the child to the allowed options and clears it if the previous choice is no longer valid. The server applies the same rule on every entry point (form, import, API, mobile app), rejecting a known option that the parent selection does not allow; legacy values that no longer exist in the list remain accepted, as in any picklist.
Deleting a field also removes it from the required fields of every pipeline stage. A stage never requires a field that no longer exists, so deleting a field can never block an opportunity from moving forward.