Nektar accesses your Salesforce organization through a designated Salesforce user, which we call the Integration User.

We recommend creating a dedicated Salesforce user account (a service account) to serve as the Nektar integration user, as this gives fine control over what data Nektar can access. If this is not possible, you may use a shared user account for all tools to access Salesforce, or use your own Salesforce user account as the Nektar integration user.

Your Salesforce administrator should provision an integration user on Salesforce before you can set Nektar up. It is also a good idea for the designated Nektar administrator in your organization to have the credentials for the integration user.

Permissions

The specific records and fields Nektar accesses may be controlled by configuring a Salesforce profile with access to only the appropriate records and assigning the Nektar integration user to that profile.

The permissions required for this profile are:

Permission Purpose
Modify All Data create and modify all Salesforce records it can access (e.g. add and update contacts and activities)
Modify Metadata Through Metadata API Functions create and modify custom fields for storing useful Nektar data
Customize Application control field-level security for Nektar custom fields
Manage Profiles and Permission Sets grant other users visibility to the data in Nektar custom fields
API access allow programmatic access
Reduced privilege alternatives

These allow operating Nektar with a less privileged integration user.

These alternatives involve setting up and maintaining complex Salesforce configurations manually, and require considerable Salesforce administration expertise.

Alternatives to “Modify all data”

Instead of providing this permission, you may use profiles or permission sets to permit the integration user to read, update, create and delete records under the specific objects that Nektar requires. Optionally, you may also:

  • Restrict the delete permission to ensure that Nektar only deletes records it created. Important: Use the CreatedById field and not the OwnerId to implement this restriction.
  • Restrict the update permission to the specific fields updated by Nektar. Note: This list may change from time-to-time based on your business requirements.
  • Restrict access to the sub-set of records (e.g. Accounts, Contacts, Opportunities, Leads) relevant to the teams adopting Nektar. Important: Relevant records not being visible to Nektar may result in duplicate contacts, activities being associated with the wrong opportunities, or other inaccuracies.

Alternatives to “Modify Metadata through API Functions”, “Customize Application”, “Manage Profiles and Permission Sets”

Instead of providing these permissions, you may set up the relevant Nektar custom fields manually. Ensure that:

  • the field API names and picklist values are spelled accurately, with the correct case and punctuation
  • read and write access to these custom fields are provided to the Nektar integration user
  • read access to these custom fields are provided to all normal user profiles as required