There are many factors that comes when we are
doing some integration with another system. When using the API, the following factors affect access to your
organization’s data:
1. Access:
Your organization must
be enabled for API access.
2. Choosing a WSDL:
Here are two Force.com Web services for which you can obtain WSDL files
for API access:
a) Force.com EnterpriseWSDL
This API is for most enterprise users who are
developing client applications for their organization. The enterprise WSDL file
is a strongly typed representation of your organization’s data. Note the following when generating the enterprise
WSDL:
1) If new custom fields or objects are
added to, renamed, or removed from your organization’s information, you need to
re-generate the WSDL file in order to access them.
2) The generated WSDL contains the
objects and fields in your organization, including those available in the
selected versions of each installed package. If a field or object is added in a
later package version, you must generate the enterprise WSDL with that package
version to work with the object or field in your API integration.
b) Force.com Partner WSDL—
This API is
for salesforce.com partners who are developing client applications
for multiple organizations. As a loosely-typed representation of
the Salesforce object model, the partner
WSDL can be used to access data within
any organization.
3. User Permissions:
A user attempting to access
the API must have the permission “API Enabled” selected. It’s
selected by default.
4. 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 thedescribeSObjects() call on the object and inspect
the properties in the DescribeSObjectResult.
5. Page Layouts and RecordType:
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.
6. Object-Level and Field-Level Security:
The API respects
object-level and field-level security configured in the user interface. You can
access objects and fields only if the logged-in user's permissions and access
settings allow such access. 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.
