API and Dynamic Apex Access in Packages

Considerations for API and Dynamic Apex Access in Packages

By default, dynamic Apex can only access the components with which the code is packaged. To provide access to standard objects not included in the package, the developer must set the API Access.

1. From Setup, enter Packages in the Quick Find box, then select Packages.
2. Select the package that contains a dynamic Apex that needs access to standard objects in the installing organization.
3. In the Package Detail related list, click Enable Restrictions or Restricted, whichever is available.
4. Set the access level (Read, Create, Edit, Delete) for the standard objects that the dynamic Apex can access.
5. Click Save.

Choosing Restricted for the API Access setting in a package affects the following:

• API access in a package overrides the following user permissions:
  • Author Apex
  • Customize Application
  • Edit HTML Templates
  • Edit Read Only Fields
  • Manage Billing
  • Manage Call Centers
  • Manage Categories
  • Manage Custom Report Types
  • Manage Dashboards
  • Manage Letterheads
  • Manage Package Licenses
  • Manage Public Documents
  • Manage Public List Views
  • Manage Public Reports
  • Manage Public Templates
  • Manage Users
  • Transfer Record
  • Use Team Reassignment Wizards
  • View Setup and Configuration
  • Weekly Export Data
• If Read, Create, Edit, and Delete access aren’t selected in the API access setting for objects, users don’t have access to those objects from the package components, even if the user has the Modify All Data and View All Data permissions.
• A package with Restricted API access can’t create users.
• Salesforce denies access to Web service and executeanonymous requests from an AppExchange package that has Restricted access.

The following considerations also apply to API access in packages:

• Workflow rules and Apex triggers fire regardless of API access in a package.
• If a component is in more than one package in an organization, API access is unrestricted for that component in all packages in the organization regardless of the access setting.
• If Salesforce introduces a new standard object after you select restricted access for a package, access to the new standard object isn’t granted by default. You must modify the restricted access setting to include the new standard object.
• When you upgrade a package, changes to the API access are ignored even if the developer specified them, which ensures that the administrator installing the upgrade has full control. Installers must carefully examine the changes in package access in each upgrade during installation and note all acceptable changes. Then, because those changes are ignored, the administrator must manually apply any acceptable changes after installing an upgrade.
• S-controls are served by Salesforce and rendered inline in Salesforce. Because of this tight integration, there are several means by which an s-control in an installed package could escalate its privileges to the user’s full privileges. In order to protect the security of organizations that install packages, s-controls have the following limitations:
  • For packages you’re developing (that is, not installed from AppExchange), you can only add s-controls to packages with the default Unrestricted API access. After a package has an s-control, you can’t enable Restricted API access.
  • For packages you’ve installed, you can enable access restrictions even if the package contains s-controls. However, access restrictions provide only limited protection for s-controls. Salesforce recommends that you understand the JavaScript in an s-control before relying on access restriction for s-control security.
  • If an installed package has Restricted API access, upgrades are successful only if the upgraded version doesn’t contain any s-controls. If s-controls are present in the upgraded version, you must change the currently installed package to Unrestricted API access.