Allow Auto Number as the primary display field for Custom Objects
S
Sebastian Castro Alvarado
Problem
When creating a Custom Object, the primary display field can only be a single-line text field. There is no Auto Number option, so every record has to be named by hand or by a workflow.
This forces a bad trade-off:
Mark the field as unique and you cannot store two records that legitimately share that value — for example two batches of the same product reference, where the batch number is what actually needs to be traced.
Leave it not unique and records end up with duplicated or inconsistent names, which breaks list views, search and reporting.
In our case (a tattoo studio with health and traceability records) we hit this twice: once with session records, once with materials. Both are high-volume objects where a human-typed identifier is a guaranteed source of errors.
Proposed
Add Auto Number as a field type for the primary display field, with:
a configurable prefix (SES-, MAT-),
a configurable starting number and padding,
uniqueness enforced by the system instead of by the user.
This already exists for other record types in the platform, so the concept is not new to users.
Also, please expose it through the API
POST /objects/ currently rejects anything other than TEXT in primaryDisplayPropertyDetails.dataType:
{"message":["primaryDisplayPropertyDetails.dataType must be one of the following values: TEXT"],
"error":"Unprocessable Entity","statusCode":422}
Agencies that provision sub-accounts programmatically cannot create properly-keyed objects today; everything has to be finished by hand in the UI.
Why it matters
The primary field cannot be changed after creation. Getting it wrong means rebuilding the object and recreating every custom field on it — in our case 69 fields. A one-line choice at creation time has a very expensive mistake attached to it.
Log In