In the Salesforce user interface, you can extend your organization’s Salesforce data by defining custom objects. Custom objects are custom Salesforce database tables that allow you to store information unique to your organization. For custom objects, the custom flag—a Boolean field in the DescribeSObjectResult—is true.
Client applications with sufficient permissions can invoke API calls on existing custom objects. You can create new custom objects using the metadata WSDL with a client application or using the Force.com IDE. For more information about using the metadata WSDL to create new custom objects, see the Force.com Metadata API Developer's Guide. For more information about the Force.com IDE, see developer.force.com.
Use the following topics to understand how the API interacts with custom objects and fields:
Custom objects have an associated name field that is defined by your Salesforce administrator during setup. Custom objects must have unique names within your organization.
In the API, the names of custom objects are identified by a suffix of two underscores immediately followed by a lowercase “c” character. For example, a custom object labeled “Issue” in the Salesforce user interface is seen as Issue__c in that organization’s WSDL.
Relationships change the naming convention, see Relationships Among Custom Objects for more information.
In order 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 does not have a name, then the ID of that record will be used as its name.
Custom objects relate to other objects and behave just like standard objects, as described in Relationships Among Objects. For example, cascading deletes are supported in custom objects in a Master-Detail relationship.
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, and "__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, and the parent object pointer becomes MyRel__c, and the relationship name is MyRel__r. For more information, see Understanding Relationship Names and Custom Objects and Custom Fields.
| Standard Object | Master-Detail | Lookup | Custom Fields |
|---|---|---|---|
| Account | Yes | Yes | Yes |
| Campaign | Yes | Yes | Yes |
| Case | Yes | Yes | Yes |
| Contact | Yes | Yes | Yes |
| Contract | Yes | Yes | Yes |
| Event | No | No | Yes |
| Lead | No | No | Yes |
| Opportunity | Yes | Yes | Yes |
| Product2 | No | Yes | Yes |
| Solution | Yes | Yes | Yes |
| Task | No | No | Yes |
| User | No | Yes | Yes |
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 can have the same audit fields as standard objects. Your organization must be API enabled and have the ability to create audit fields enabled, and you must have the “Modify All Data” permission.
When you create a custom object, the four audit fields CreatedById, CreatedDate, LastModifiedById and LastModifiedDate are automatically created and populated for the object. These fields are read only.
For more information about audit fields, see System Fields.
A sharing rule object is created for each custom object that does not have a master-detail relationship to another object. They are similar to standard object sharing rules, for example AccountOwnerSharingRule. If the user creating the custom object has the "Manage Users" permission, a sharing rule object is automatically created for it.
In the Salesforce user interface, you can mark a custom field as required, and this is also enforced in the API. Every custom field has a field isRequired, with a data type boolean. The default value is false. If set to true, every request must supply a value (or leave the current value) to this field. Otherwise, the request will fail. Once the value is set to true, the next time the field is edited or created, the validation will apply, and if there is no value supplied or default value specified, the request will fail.
To edit the isRequired field, 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 always 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 does not have a specified or default value, an error with the status code REQUIRED_FIELD_MISSING is returned. For more information, see About Universally Required Fields in the Salesforce online help.
If you have an unmanaged package and a managed package version becomes available, the API names of custom fields, custom objects, and Scontrols in the package will change, because a namespace prefix is added to each of these components to make them unique: name__c becomes prefix__name__c. To move from an unmanaged package to a managed package version of the same application, we advise that you export the data, uninstall the old package, install the new package, review the name changes, and import with the relevant mapping. For details, see the Salesforce online help topic About Managed Packages.