2

My requirement is that sales reps cannot create or edit accounts but we want to enable them to convert leads when there is an existing account in place, in order to create new contacts and Opportunities under them.

  • I have written a custom Lead Convert page that allows them to lookup an existing Account and then the controller code will call the database.leadconvert() method to convert the lead to that Account. However SF requires that the user running this operation has edit rights on the Account in order to convert a lead under it, even if I declare the class as without sharing. Shoot.
  • I next tried to give them edit perm on the Account and then lock down anything I could to prevent them from editing accounts - removed the Edit button from layout, made all fields on the layout readonly etc. But this is a pain and there are some fields we just can't lock down, like Name and Owner. It allowed them to convert but too many bad side effects.

  • My next brain wave was to insert a permission set assignment record giving them edit permission, convert the lead and then delete the permission set assignment. This seemed awesome until I hit the Mixed DML error when trying to convert the lead after inserting the Permission Set Assignment.

    Any ideas on how to get around the mixed DML? I don't really want any part of this to be @future since I need to show the user any error messages from the lead conversion operation or take them to the Account page after it completes. 

    // if user doesn't have edit rights on Account, add the permission set now
    if (!Account.sObjectType.getDescribe().isupdateable()) {
        permAdd = new PermissionSetAssignment(PermissionSetId = '0PS80000000blLl', AssigneeId = UserInfo.getUserId());
        insert permAdd;
    }
    // prepare lead conversion here...snipped for brevity

    //convert the lead
    Database.LeadConvertResult leadConvertResult = Database.convertLead(leadConvertObj);
    if (permAdd != null)
        delete permAdd;
Improve this question
3
  • It sounds as though the portions of the Account you want to update are the related Contact that you're going to create during the conversion along with the related Opportunity. Off hand, those would seem to be the only fields you need to unlock on Accounts for them unless you have custom fields you also want populated during the conversion. It possible that you may be making this more complicated for yourself than it needs to be. You might also want to think about creating a Visual Flow to simplify doing this.
    – crmprogdev
    Commented Nov 6, 2014 at 0:56
  • My issue is that I get errors when the lead conversion code runs as a user without Account Edit, even w/o the 'with sharing' keywords. Is there a Visual Flow component for converting leads that ignores the permissions for the user? We actually don't need to update anything on the Account, only create contacts and Opps based on their selection in the convert page. I thought about just using code to create the Contact and Opp rather than converting the lead but then the Lead is left as not yet converted and I would have to manage the lead mapped fields myself which is a pain.
    – nikiV
    Commented Nov 6, 2014 at 17:50
  • I don't have an answer for you without going through the process of creating the flow myself. Next week I'm to begin creating the first of several lead conversion flows for a local non-profit. You might try capturing the flow error that's generated from not being able to edit Accounts and see if you can create a flow path that forks around it because the acct already exists, thus allowing you to convert because no new acct needs to be created.
    – crmprogdev
    Commented Nov 6, 2014 at 18:44

1 Answer 1

Reset to default
0

Good solution the 3rd one (given all the limitations of the case).

Anyway. To avoid the Mixed DML error you could split the operation in 3 different transactions, "almost seamlessly" to the User, using good old (but still well used with OAUTH) white web page with location refresh header.

Using this technique you can make your Users:

  1. get the permission set - redirect...
  2. convert the lead - redirect...
  3. get the permission set removed - get finally redirected to next step in process

which is suboptimal but still makes the way for what you need.

The only security spot I see is in the case a User clicks on "Stop loading page" while in the middle of that. A scheduled class/future method to check the User isn't a bad guy? But that's another story.

Improve this answer
2
  • In the end I had to create 4 VF pages in a chain. Pg 1 to capture Lead conversion details, pg 2 to add Permission Set Assignment if needed, pg 3 to add AccountShare if needed, convert the lead and delete the AccountShare if added (thankfully those can be done together with mixed DML errors) and pg 4 to delete the Permission Set Assignment if added and send them to the Account. It does show all white in the browser as these pages cycle along but thankfully it's only a few seconds so hopefully users won't be impatient.
    – nikiV
    Commented Nov 6, 2014 at 21:02
  • Glad to hear you're satisfied with the solution. Hacky is the way ;-)
    – MLucci
    Commented Nov 6, 2014 at 23:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .