function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

DML not allowed on ContactShare

I'm trying to write a trigger on a custom object that will insert/update/delete ContactShare records upon insert/update/delete of the custom object.
I have been running into a wall where Salesforce simply won't allow me to save and gives me only an "unknown error".
I recently moved my code to a different dev org and the same code gets a new error.  "DML not allowed on ContactShare"
I have found a bunch of old posts with the same sort of error but no real resolution to any of them and a few allude to the possibility that this is some kind of bug.
Is this a bug, is there some way around it, if DML is not allowed what other methods of Insert/Update/Delete are available?
Thanks alot
Jon -

Not sure if this will address your issue, but have you tried doing the DML in a deferred method - one that uses the future annotation?  That might help.

Hope this helps.
I hadn't tried @future, until now.  I get the same results.
Here is my code, if it helps any.


public static void InsertContactShare(id newContactId, id newOwnerId)


// insert a new contactshare record providing Contact access to a User

//instantiate the object

ContactShare theShare = new ContactShare();

//update the object

theShare.ContactAccessLevel = 'Edit';

theShare.ContactId = newContactId;

theShare.UserOrGroupId = newOwnerId;

//insert it into salesforce

insert (theShare);  //this line results in  "Save Error: DML not allowed on ContactShare"






DML on ContactShare is allowed.  I think the error message is a bit misleading.  I don't believe DML was allowed on ContactShare because your organization sharing model for contacts is public read/write - the ContactShare object is not exposed in this case.  Try setting the sharing model for Contacts to private and rerun your logic.


Thanks for the info.

I set the contact sharing rule to private on my dev org and that seems to do the trick. 

So because I don't need it, I don't even get access to the object.  It seems odd that Salesforce would bother to waste the time of taking it away from me when I don't technically need it.

Unfortunatly my problem still is not fixed.   I checked my client's org and found that they have Contact security set to "Public Read Only".  I would expect that I would have access to the ContactShare in order to give Read/Write access, as I am trying to do above but am not able.  Is there some other security setting that I'm missing?


Thanks again for your help.




I'm assuming Contact is controlled by the Parent (Account) - if it is I don't believe the ContactShare is exposed.

"I'm assuming Contact is controlled by the Parent (Account) - if it is I don't believe the ContactShare is exposed."


If that were the case, what would be the point of being able to set security on Contact?

There IS a "Controlled by Parent" security setting, but in this case Contact is set to Public Read Only. 

Account IS set to Public Read Write, so you may be correct, but that would negate the Public Read Only setting on Contact which doesn't really make any  sense.


As a test I just set security on my dev org to the same as that at my client.

Account = Public ReadWrite  Contact = Public ReadOnly

I no longer get the "DML not allowed" error, everything appears to work perfectly.  Yet at the same time I'm still getting the unknown error on my client's org, using the exact same code and the same security settings.

Apparently my unknown error is NOT the DML error on my client's org.   I had assumed that the two orgs were having the same problem but for some reason the error was different on my dev org, apparently the same code has different problems on different systems.

I'm again at a loss because I have no idea what the error is.  It simply reads "Save error: Unable to perform save on all files: An unexpected error has occured.  Please try again, or check the log files for details"  The log files are basicly useless, they don't show any more information then the error reads above.


Thanks again for your help



Message Edited by JonSimmons on 11-06-2008 05:14 PM