Salesforce Integration notes

Create and use an Integration user with Admin profile

This is so that you have an integration user independent of your actual users. If you were to use an actual user, if and when they leave or change roles in your company, you'll have to configure another user. Don't do this and instead save yourself the trouble and create a user named Integration User instead. See reference 1 for more information about this.

You can also create one more user named Data Migration with the same configuration and use this for all data loads into Salesforce. This allows you to figure out if the record was created (or updated) by someone doing a data migration or was touched through external integration

Finally create one more similar user named Code Migration. This allows your deployment team to login to production and deploy code without having to reuse or know the Integration or Data Migration credentials.

Bypass Triggers for this Integration or Data Migration user

Turning off triggers in production is a pain and requires a changeset deployment to turn off. Instead while developing the trigger itself, add code to bypass it for the Integration and Data Migration users. This is something you'll need to be careful of, since in some situations you might need the triggers to fire. So think about this carefully

Bypass validation rules and workflows for this Integration or Data Migration user

When doing a data load or an API integration, you may not want any validations to occur or workflows to run. Add these users as a check in the validation rule and workflow so that the validation rule and workflow gets bypassed if the user name is Integration or Data Migration

Make Contacts owned by the Integration user

Contacts are normally owned by the user who created them. This causes an issue when the person leaves the organization which makes the contact uneditable (if org wide default is private or public read only). (This problem - editing records of inactive users - is solved in Winter 16 - see reference 3 below). Also record owners are able to delete contacts they own. To prevent this, write a workflow rule which changes the contact owner to the Integration user immediately on contact creation. Then share the contact (through criteria based sharing settings) with only the roles which need access

References

1. User Permission for API Integration User [help.salesforce.com]
2. Locking Down Record Access in Salesforce [developer.salesforce.com] 
3. Set Audit Fields and Update Records with Inactive Owners [releasenotes.docs.salesforce.com]

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.