Required Fields and Uniquiness

Hi Matthew -

There are plans for required fields for the new custom objects. We will start working on this in H2 this year.

Uniqueness is something that we have discussed internally. There are 2 features in mind here:

1) Unique Name field value - When creating a Custom object, the admin will have the ability to define the name field as unique.

2) Auto increment - when creating a custom object, the admin will have the ability to create an auto increment field that will increment for each record. 

 Having said that, if you were to suggest a relative priority between Uniqueness and Required field, which one would be higher priority for you?

That is difficult as both are needed for our use cases if we were to take advantage of the out of box UI in the future. 

In many instances a unique name field may not be the most desired outcome or at least the field labeled Name.

Example: Registered Product object is used to track the products associated to a user. The Name of the product is not unique and is stored in the name field. The serial number of the product is unique and stored in the Serial Number field. The ticket lookup and would need to filter records from the Registered Product object such that they would only display records which are associated to the ticket requester.  A filtered lookup.

If only one field on the object is able to be unique then the field should be able to be defined. The label Name is not applicable in all use cases. 

A unique field or an Auto increment field with a defined prefix example: Order-12345 OR Registration-12345 OR c12345 OR mov12345 would be preferred. Without the option of a prefix it may become difficult to identify the record from other objects or when troubleshooting data issues in downstream systems.