Standard versus custom attributes
What you can change about the fields that shipped with the product, and what you deliberately cannot.
Some attributes ship with the product and the whole system depends on them — lead stage drives the calling list, phone drives dialling, assignment drives visibility. Those are standard attributes, and they cannot be renamed, retyped or deleted.
That restriction prevents the classic CRM disaster: repurposing a system field for a different meaning, which works fine until something downstream reads it literally and behaves in a way nobody can explain.
Steps
Know what a standard attribute is
The fields the product itself acts on. Lead stage is the clearest example: six of its values remove a contact from the calling list.
Know what you can change about them
You can make them required or admin-only, and you can set a default. That is enough for most real needs.
Know what you cannot
They can never be renamed, retyped or deleted, because too much of the product reads them by meaning rather than by label.
Add a custom attribute rather than repurposing one
If you want a field to mean something other than its name, you want a new field. Using "source" to store a territory is the kind of decision that outlives everybody involved.
Delete custom attributes carefully but freely
Custom attributes can be deleted, with a two-step confirm naming how many contacts lose the value. That is a real safety net, and it means you can experiment.
Check it worked
Read your custom attribute list and ask, of each: would a new colleague guess what this holds from its name alone? Anything that fails that test is a field that will be filled in inconsistently.
The parts people get wrong
- If you want a field to mean something different from its name, you want a new field. That rule saves more pain than any other in CRM administration.
- Standard attributes appear in the same editor as custom ones, with the unavailable options simply not offered.