I'm trying to delete leads after converting to contacts, but getting the exception 'DML statement cannot operate on trigger.new or trigger.old'.
Below is the code where I'm facing issue at delete leadListToDelete. Can any explain this? 

trigger LeadToContact on Lead (before insert, before update, after insert, after update) {   
    //Map<Id, Lead> leadIds = new Map<Id, Lead>();
    List<Lead> leadList = new List<Lead>();
    List<Lead> leadListToDelete = new List<Lead>();
    
    if(trigger.isBefore){
    	for (Lead l : trigger.New){
        	if(l.Status == 'Open - Not Contacted'){
            	if(l.Email_Domain__c != null){
                	leadList.add(l);
                 	System.debug('New leads having Email domain ### ' + leadList);
            	}
        	}
    	}
    
    	List<Account> accList = [select id, Email_Domain__c from Account where Email_Domain__c LIKE '%com'];        
    	List<Contact> contactList = new List<Contact>(); 	
   
    	for(Account acc :accList){
        	for(Lead lead : leadList)
            	if(acc.Email_Domain__c == lead.Email_Domain__c){
                	Contact c = new Contact(LastName = lead.LastName, AccountId = acc.Id);
                	contactList.add(c);
                    System.debug('Contacts to be created : ' + contactList);
                	leadListToDelete.add(lead);
                    System.debug('Delete Leads ## ' + leadListToDelete);
            	}
    	}
    
    	insert contactList;
    	delete leadListToDelete;
    	}
 
}

Thanks in Advance!

Hi, so our salesforce system has a custom object, what we need to do is transfer the information from the Lead object to our custom object called momentum_Prospect__c . The trigger has to run when data has been added to the Lead Object from the web 2 Lead form. Does anybody have any idea how this can be executed? Please help!

Hi All,

We are using communities and we have this use case where a community user's got to see only those accounts which he has created and not any other accounts. Is there any way to restrict the view filter in accounts for a specific profile?
As, of now i cannot make account private because its child objects i.e case and opportunity will also become private which is not what we wanted as there are child objects to case.

Any suggestion to resolve this issue will be appreciated.

Thanks,

Bharath Kumar M

I have a custom field on the Lead level called Email Domain, as well as on the Account level.  
Can someone help me create a trigger, where any Leads that have Lead Status = Open are converted as Contacts into Accounts if the Email Domain field on the Lead and Account matches.

For Example;
Lead
Name - John Smith  
Lead Status - Open
Email - j.smith@abc.com
Email Domain - abc.com

Account 
Account Name - ABC
Email Domain - abc.com

Then the Lead John is converted into a Contact that belongs to Account ABC

Posting this in order to help others who, months from now, might Google "OP_WITH_INVALID_USER_TYPE_EXCEPTION" and find this explanation.

 

We wrote an Apex trigger on the User object, to insert a custom object record anytime a user updates their Chatter status.  This was done to fulfill a client's requirement to audit all Chatter activity.

 

The trigger worked fine, until one day the client signed up some Chatter Free users.  When such a user tried to update their status, they got a pop-up with an OP_WITH_INVALID_USER_TYPE_EXCEPTION error.

 

We scratched our collective heads for awhile.  After all, Apex triggers run in "system mode," right?  That is supposed to mean that "object and field-level permissions of the current user are ignored."  And yet this trigger seemed like it was running in "user mode," enforcing restrictions based on who the current user was.

 

The root cause turned out to be that a Chatter Free user cannot be the owner of a custom object record, and SFDC by default sets the current user as a new record's first owner.  We discovered this when we realized, via experiment, that Apex triggers fired as the result of actions by Chatter Free users could definitely update an existing record, but were having problems creating records.

 

So the simple solution was to explicitly set the owner of the new record to some fully-licensed user prior to inserting it.