This post will be updated from time to time and serves as a knowledge base for how not-so-obvious SFDC error messages might be resolved. A running list based on personal experience

INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY

1. Public read-only sharing model on Parent__c
2. Parent inserted by user A
3. User B inserts/updates child record within master-detail relationship to Parent__c
4. No sharing rule extending write access to User B for Parent__c. For example, testmethod user not in a role that has Parent__c shared to.

1. Private OWD sharing model on Parent__c. Criteria-based sharing to extend owners of Parent__c to user B’s role
2. Apex testmethod context
3. User A inserts Parent
4. User B inserts child record with lookup to Parent__c
5. Apex testmethods do not honor criteria-based sharing. Workaround is to insert Parent and Child by same user

1. Object X has lookup relationship to Object Y
2. When Object X is inserted or updated, if the value of X.lookup_y__c is to an id that is valid for Object Y’s type but does not exist in the database
3. Typical examples occur when cloning X from something else or sync’ing X from a different SFDC org

1. Detail Object D is detail to master Object M
2. When operation is via API or APEX
3. When Object D is inserted without a value for the master’s ID field. (example: insert OrderItem without OrderItem.OrderId
4. Typical example is a misconfigured middleware operation wherein you were expecting to do an update but configured as an insert. Will not be caught in standard UI as the master field is required on the page layout.

INVALID_CROSS_REFERENCE_KEY

1. Insertion of an OpportunityLineItem, QuoteItem, or OrderItem
2. PricebookEntryID references a PricebookEntry for Pricebook P
3. Parent Opportunity, Quote, or Order has Pricebook2Id of Pricebook Q

INVALID_PARTNER_NETWORK_STATUS
Either:

1. Active connection to partner org
2. sObjects not published to partner org
3. You insert those sObjects in your code/testmethods

or …

1. Active connection to partner org
2. sObjects published to partner org
3. sObjects not subscribed within partner org
4. You insert those sObjects in your code/testmethods

or …

1. Active connection to partner org
2. Sharing a child record (like an Opportunity)
3. But, the parent record (like an Account) has not yet been accepted

INVALID_SSO_GATEWAY_URL

1. Running user has no Federation Id and
2. Running user’s profile is defined with ‘Is Single Signon Enabled’ as true

You cannot unset the role on the owner of a portal an account which has partner users.

1. You are trying to remove (not replace) the role from a User u
2. That user is the Owner of one or more Accounts that have been enabled as Partner Accounts. (Using SFDC Partner Portal)

The solution is to find all such Accounts owned by User u that are Partner Accounts. You can use a List View to do this, filtering on Partner Account = true. In our use case, we were no longer using Partner Portal and were doing role cleanup so simply disabling each Account as a ‘partner account’ using the Manage External Accounts button on the Account detail page was all that was required. If said accounts are still valid as Partner Accounts, change the owner to some other owner that does have a role.

ANT build: MapHighlightAction is not a standard action and cannot be overridden.

1. This is an object with address fields like Contact
2. Your dev sandbox does not have Google Maps enabled – Setup | Customize | Maps and Locations | Settings but your target deployment org does have Google Maps enabled.
3. The metadata for the dev sandbox SObject (e.g. Contact) will include lines as shown below

     <actionOverrides>
        <actionName>MapHighlightAction</actionName>
        <type>Default</type>
    </actionOverrides>

What seemed to be happening is that when you deploy an SObject like Contact from dev sandbox without Google Maps enabled, if the target sandbox/prod org does have Google Maps enabled, the above lines generate the error MapHighlightAction is not a standard action and cannot be overridden.

If you enable Google Maps in your dev sandbox, and examine the Contact.obj metadata, the above lines are removed and, assuming your target deployment org also has Google Maps enabled, the deployment will succeed. We encountered this issue when we did our first dev sandbox to fullcopy sandbox deployment using an SObject (Contact) with address fields. The dev sandbox was created pre-V33 but upgraded to V34 whereas the fullcopy sandbox was created V33 and also upgraded to V34. V33 was when Google Maps was introduced.

ANT build: Required field is missing

1. You have an Eclipse project with package.xml against your dev sandbox at Version x
2. Your Ant build against staging sandbox uses package.xml at Version x+n, n> 0
3. You run ant from your local GIT repo (containing your metadata files, like xxx.workflow) against your staging sandbox, using the staging sandbox package.xml

What seems to happen is the package.xml file in your dev sandbox Eclipse is defaulted to the earliest version of any class in your project. In my case it was V15.0. However, the Ant build against Staging sandbox used package.xml at V30.0. When you get metadata from the dev sandbox into Eclipse, the metadata files are presented according to what is supported by the dev sandbox’s package.xml version #. Using V15.0, the metadata for xxx.workflow files is no longer compatible with V30.0 (email alerts need to have descriptions, tasks need to have subjects).

The solution is to update the package.xml file in the dev sandbox to the same version as used in the ant build. Then refresh the src tree in the Eclipse dev project

There is already a Child Relationship named Foos on Bar

1. You are doing a ChangeSet deployment of a lookup custom field Bar__c on Sobject X
2. The parent SObject (Foo) of the lookup field Bar__c has a child relationship named Foos (Foos__r)
3. You haven’t changed anything on X or changed anything about the lookup field or its child relationship name. In sandbox there are no duplicates. In PROD, the Sobject X doesn’t even exist.

A likely cause of this is that in PROD, you have a deleted SObject X with field Bar__c. But the deleted object is within the 45 day window before it is permanently deleted by Salesforce. Hence, when the changeset comes through, SFDC thinks there is already the child relationship (albeit in a deleted sobject) and considers your change to be a duplicate.

The solution is to Erase the deleted Sobject in the target org (PROD) and retry the deployment of the Change Set.