ERR_PERMISSION_DENIED on Salesforce: Permission denied — Salesforce returns "INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY", "FIELD_INTEGRITY_EXCEPTION", or "You do not have the level of access necessary to perform the operation you requested". Root cause: Salesforce has a layered permission model: Organisation-Wide Defaults (OWD) set the baseline access, Profiles define what objects and fields a user can see and edit, Permission Sets add additional access on top of the profile, and Sharing Rules control record-level visibility. A permission denied error means the authenticated user (or the integration user your tool connects as) is missing access at one or more of these layers. The most common cause in integrations is that the integration user's profile was not updated when new custom fields or objects were added. Step 1: Read the exact error message to identify the permission layer. The Salesforce error code tells you which layer is failing. "INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY" means OWD or sharing rules are blocking access to a related record. "FIELD_INTEGRITY_EXCEPTION" means field-level security is blocking a field write. "ENTITY_IS_DELETED" means the record was deleted and you are trying to access it. "INVALID_CROSS_REFERENCE_KEY" means a lookup field references a record the user cannot see. Each requires a different fix. Step 2: Check the integration user's profile permissions. In Salesforce Setup, go to Users → find the integration user → click their Profile name. Under Object Settings, find the object causing the error. Confirm the user has Read, Create, Edit, or Delete access as required. If the profile is a standard profile (e.g., Standard User), you cannot edit it — clone it first (Profile → Clone), make the changes on the clone, and reassign the user to the cloned profile. Step 3: Check field-level security for the specific field. Go to Setup → Object Manager → [Object] → Fields & Relationships → click the field name → Set Field-Level Security. Find the integration user's profile in the list and confirm the field is set to Visible and not Read-Only (if you need to write to it). Alternatively, go to the profile directly → Field-Level Security → select the object → edit the field access there. Step 4: Check Organisation-Wide Defaults and Sharing Rules. If the user can access the object but not specific records, the issue is OWD or sharing. Go to Setup → Sharing Settings. Check the OWD for the object — if it is set to "Private", users can only see records they own or records shared with them. To grant broader access, either change the OWD (affects all users), create a Sharing Rule to share records with a specific role or group, or use a Manual Share on the specific record. Step 5: Use Permission Sets for integration-specific access. Rather than editing the integration user's profile (which may be shared with other users), create a dedicated Permission Set for your integration. Go to Setup → Permission Sets → New. Add the required object permissions and field-level security. Assign the Permission Set to the integration user only. This is the recommended approach — it keeps integration access isolated and auditable. Step 6: Test the fix with the Salesforce API Workbench. Before re-running your integration, test the fix using Salesforce's API Workbench (workbench.developerforce.com). Log in as the integration user, run a SOQL query on the object, and try a REST API call to create or update a record. If it succeeds in Workbench, the permission is correctly configured. If it still fails, the permission layer you fixed was not the only one blocking access.