Custom Objects

Naming Conventions for Custom Objects

Your Salesforce admin defines an associated name field for each custom object during setup. Custom objects must have unique names within your org.

In the API, the names of custom objects include a suffix of two underscores followed by a lowercase “c”. For example, a custom object labeled “Issue” in the Salesforce user interface is Issue__c in that organization’s WSDL.

Relationships change the naming convention. See Relationships Among Custom Objects for more information.

For a custom object record to appear in the Salesforce user interface, its name field must be populated. If you use the API to create a custom object record that doesn’t have a name, the record’s ID is used as its name.

Relationships Among Custom Objects

Custom objects behave and relate to other objects just like standard objects do, as described in Relationships Among Objects. For example, cascading deletes are supported in custom objects in a master-detail relationship.

Custom objects can also have many-to-many relationships with other custom objects or standard objects. A many-to-many relationship allows each record of one object to be linked to multiple records from another object and vice versa. For more information, see Relationships Among Objects.

Custom objects require special treatment so that they can participate in Relationship Queries. For the relationship field name of a custom object, __r is appended to the name to create the ID. Also, __c is appended to the name to create the parent object pointer. For example, if the relationship field name is MyRel, the name of the ID becomes MyRelId__r, the parent object pointer becomes MyRel__c, and the relationship name is MyRel__r. For more information, see Understanding Relationship Names, Custom Objects, and Custom Fields in the Salesforce SOQL and SOSL Reference Guide.

Audit Fields for Custom Objects

Custom objects can have the same audit fields as standard objects. When you create a custom object, the four audit fields, CreatedById, CreatedDate, LastModifiedById, and LastModifiedDate, are created and populated for the object. These fields are read only. If you import data into Salesforce custom objects and want to retain the audit field values from the source system, you can set the values when you create the custom objects. The only audit field you can’t set a value for is SystemModstamp. Your organization must be API enabled, and you must have the “Modify All Data” permission.

1. From Setup, enter User Interface in the Quick Find box, then select User Interface under Customize.
2. Under Setup, select Enable “Set Audit Fields upon Record Creation” and “Update Records with Inactive Owners” User Permissions.
3. In the permission set or profile that you want to set audit fields with, enable the permission Set Audit Fields upon Record Creation.
4. Using the API, create a record and set its audit fields.

For more information about audit fields, see System Fields.

Sharing and Custom Objects

A sharing rule object is created for each custom object that doesn’t have a master-detail relationship to another object. They’re similar to standard object sharing rules, for example AccountOwnerSharingRule. If the user creating the custom object has the “Manage Sharing” permission, a sharing rule object is automatically created for it.

Apex sharing reasons can be retrieved describing the custom object's sharing object, and examining the information in the rowCause field. The name of a sharing object for each custom object is of the form: MyObjectName__Share, similar to AccountShare and other standard object sharing objects.

Tags and Custom Objects

When a custom object is created, a Tag object related to it’s also created. These object names are of the form: MyObjectName__Tag, similar to AccountTag and other standard object tag objects.

Standard Fields for Custom Objects

When a custom object is created, Salesforce assigns some standard fields to the object or entity. For details, see Custom Objects.

Required Fields in Custom Objects

In the user interface, you can mark a custom field as required, and this rule is also enforced in the API. Each custom field has a nillable attribute, with a data type boolean. The default value is false. If set to true, each request supplies a value (or leaves the current value) to this field. Otherwise, the request fails. When the value is set to true, the next time the field is edited or created, the validation applies. If no value is supplied or default value specified, the request fails.

To edit the nillable attribute, you must log in as a user with the “Customize Application” permission.

If you change a custom object field to be required in an existing client application or integration, be sure that a value is supplied for that field. For example, if the custom picklist field Education Level on the contact object is required, supply a default value for that custom field. If a required field doesn’t have a specified or default value, an error with the status code REQUIRED_FIELD_MISSING is returned.

Managed Packages and API Names

If you have an unmanaged package and a managed package version becomes available, the API names of custom fields, custom objects, and Scontrol objects in the package change. A namespace prefix is added to each component to make it unique: name__c becomes prefix__name__c. To move from an unmanaged package to a managed package version of the same application, export your data, uninstall the old package, and install the new package. Then review the name changes and import your data with the relevant mapping. For details, see the ISVforce Guide.