Factors that Affect Data Access
When using the API, the following factors affect access to your organization’s data:
- Access
- Object-Level and Field-Level Security
- Sharing
- User Permissions
- User Permissions that Override Sharing
- Objects properties
- Related Objects
- Page Layout and Record Types
Acces
Your organization must be enabled for API access.Objects may not be available until you contact Salesforce and request access. For example, Territory2 is visible only if Enterprise Territory Management has been enabled in the application. Such requirements are in the “Usage” section for each object.Sometimes a feature must be used once before objects related to it can be accessed with the API. For example, the recordTypeIds is available only after at least one record type has been created for your organization in the user interface.
- Enterprise WSDL: The generated enterprise WSDL file contains all of the objects that are available to your organization. By using the API, a client application can access objects that are defined in your enterprise WSDL file.
- Partner WSDL: When using the generated partner WSDL file, a client application can access objects that are returned in the describeGlobal() call.
Object-Level and Field-Level Security
The API respects object-level and field-level security configured in the user interface. You can only access objects and fields if your permissions allow it. For example, fields that are not visible to a given user are not returned in a query() or describeSObjects() call. Similarly, read-only fields can’t be updated.
Sharing
For most API calls, data that is outside of the logged-in user’s sharing model is not returned. Users are granted the most permissive access that is available to them, either through organization-wide defaults or manual record sharing, just as in the application.
User Permissions
A user attempting to access the API must have the permission “API Enabled” selected. It’s selected by default.Your client application logs in as a user called a logged-in user. The logged-in user’s permissions grant or deny access to specific objects and fields in your organization:
- Read—Users can only view objects of this type.
- Create—Users can read and create objects of this type.
- Edit—Users can read and update objects of this type.
- Delete—Users can read, edit, and delete objects of this type.
User permissions do not affect field-level security. If field-level security specifies that a field is hidden, users with “Read” on that object can view only those fields that are not hidden on the record. In addition, users with “Read” on an object can view only those records that sharing settings allow. The one exception is the “Edit Read Only Fields” permission, which gives users the ability to edit fields marked as read only via field-level security.
User Permissions that Override Sharing
- View All—Users can view all records associated with this object, regardless of sharing settings.
- Modify All—Users can read, edit, delete, transfer, and approve all records associated with this object, regardless of sharing settings.
- Modify All Data—users can read, edit, delete, transfer, and approve all records regardless of sharing settings. This permission is not an object-level permission, unlike “View All” and “Modify All.”
To protect the security of your data, give the logged-in user only the permissions needed to successfully execute all the calls made by the application.
Object Properties
To create an object with the create() call, the object’s createable attribute must be set to true. To determine what operations are allowed on a given object, your client application can invoke the describeSObjects() call on the object and inspect the properties in the DescribeSObjectResult.
Related Objects
Some objects depend on other objects for permission. For example, AccountTeamMember follows sharing on the associated permission-assigned object such as the Account record. Similarly, a Partner depends on the permissions in the associated .Ownership changes to a record do not automatically cascade to related records. For example, if ownership changes for a given Account, ownership does not then automatically change for any Contract associated with that Account—each ownership change must be made separately and explicitly by the client application.
Page Layout and Record Types
Requirements defined in the Salesforce user interface for page layouts and record types are not enforced by the API:
- Page layouts can specify whether a given field is required, but the API does not enforce such layout-specific field restrictions or validations in create() and update() calls. It’s up to the client application to enforce any such constraints, if applicable.
- Record types can control which picklist values can be chosen in a given record and which page layouts users with different profiles can see. However, such rules that are configured and enforced in the user interface are not enforced in the API. For example, the API does not validate whether the value in a picklist field is allowed per any record type restrictions associated with the profile of the logged-in user. Similarly, the API does not prevent a client application from adding data to a particular field simply because that field does not appear in a layout associated with the profile of the logged-in user.
