3

You can't realistically trigger an update during an update (before or after, doesn't matter, you'll get a recursive update error), and DMLOptions won't affect the current transaction. You will necessarily need to use the @future method (or Queueable, if you desire) in order to run the assignment rules. Note that under light system load, your @future method ...


3

Varun, I don't think that Salesforce sends notification emails to an internal user when a new Event is created that is assigned to that user. This functionality only exists for Tasks. To verify this for yourself, try using the standard Salesforce UI to create a new Event record assigned to a user other than yourself, and see if Salesforce sends you an email ...


2

Found the issue. under Activity Settings we need to check Enable User Control over Task Assignment Notifications checkbox.


2

I see three issues here: createTask() doesn't really belong in the controller class - it is a service available to both VF and batch use cases and belongs in a service layer - see Separation of Concerns | service layer Your execute() method needs to batch (bulk) create Tasks and insert once, not do DML for each data in execute()'s scope Your Tasks are ...


2

I have run into this new property as well and it appears to be part of the new Summer 15 release. According to page 224 of the release notes: New Properties DMLOptions.DuplicateRuleHeader Class includeRecordDetails Set to true to get fields and values for records detected as duplicates. Set to false to get only record IDs for records detected as ...


2

This is actually working as designed. The DuplicateRuleHeader.AllowSave option is really allowing for bypassing of the duplicate rule alert. If the duplicate rule specifies a blocking action this will block any and all duplicates found even when specifying AllowSave = true. There has been a documentation bug filed for this issue.


2

With thanks to gNerb and sfdcfox, here's the altered code to fix the issue: public class AssignLeadsUsingAssignmentRules{ @InvocableMethod(label='Assign Leads Using Assignment Rules' Description='Run this to re-run assignment rules on any leads needing to be re-checked.') public static void AssignLeadsUsingAssignmentRules(List<Id> LeadIds)...


2

Solved: It seems that assigning DMLOptions to SObject is not working (anymore) (according to this: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_methods_system_sobject.htm#apex_System_SObject_setOptions ): DMLOptions dmlOptions = new DMLOptions(); dmlOptions.allowFieldTruncation = true; SObject object = new Account( Name = '...


1

The settings are applied before the transaction starts; you can't modify those settings during a trigger. To fix it easily, create a custom field as you described, set it in the before-insert trigger, and then you can create a single rule entry like: Skip Assignment equals True And the Owner would be set to: Keep Owner


1

The Limits class gives you insight as to the current limits of a given transaction. Unfortunately, you can't choose to alter your batch size in the middle of an execution, which means you may need to be prepared to switch to a Queueable during execution (you're allowed 1, so use it sparingly). These limits are fixed as defined in governor limits. It is ...


1

A solution I found to this problem was: - insert the lead without specifying the Owner - subsequently update the owner to the appropriate queue using database.update(l, dmlOpt); This resulted in an email being sent to the queue members.


1

You can configure a workflow rule on Lead object which will fire during creation only. And in the workflow action, send email to the Lead owner. This email should go to all the queue members if owner is queue otherwise, it will go the user.


1

SObject setOptions does not work. Instead, use the alternative Database.insert/update(record, DMLOptions) version: Database.insert(CaseInstance, dmlOpts); ... Database.update(CaseInstance, dmlOpts); Coincidentally, you can save a query by choosing to use the Default Rule (assuming you set your rule as default): dmlOpts.AssignmentRuleHeader.useDefaultRule =...


1

The issue with synchronous is that it is an operation that can be performed through the User Interface. The documentation is clear here: DMLOptions settings take effect only for record operations performed using Apex DML and not through the Salesforce user interface Hence, you need to do DML on the Lead to set DmlOptions. As for beforeUpdate/...


1

Simply overwrite the save method in your extension: public static final String RETURL_PARAM = 'retUrl'; public PageReference save() { caseRecord.setOptions(dmo); try { insert caseRecord; } catch (DmlException dmx) { ApexPages.addMessages(dmx); return null; } String retUrl = ApexPages.currentPage()....


Only top voted, non community-wiki answers of a minimum length are eligible