9

So the issues turns out to be the DML options. In order for e-mails to get sent - even from Assignment Rules, the DML option has to be updated: dmlOpts.EmailHeader.TriggerUserEmail = true; Otherwise it will ignore any email trying to be sent internally that is not called by apex directly.


8

If this is a before insert trigger, will this owner persist, or will the default case assignment owner be set as the owner anyway. Assignment rules run after triggers do. See Triggers and Order of Execution for more details. Is there a way to access the 'Assign using assignment rules' attribute from the trigger so I can assure it isn't assigned using ...


6

Figured this one out myself - hopefully this answer helps someone else. In the lead settings, there is a setting to Override the existing record type with the assignee's default record type. Updating this to keep the existing record type solved the issue for me. See screen below:


6

Lead reassignment within a trigger can be done with future methods such as the following. Your after insert / after update trigger will need to collect up a set of lead ids that qualify for reassignment and then once all other afterinsert/afterupdate operations are complete, call the future method below: Note use of DmlOptions: @future public static void ...


6

Take a look at this help article: Considerations before having Create Audit Fields enabled: Salesforce has the ability to set system fields through the API. When you are migrating data from an external system, the API lets you set a number of fields on objects that were previously read-only. By setting these fields, records will appear to have been ...


5

What's the order of assignment rules? The first rule that "hits" is selected (like in approval processes), make sure your "Unassigned" is listed as last option. Are you ticking the checkbox "assign using active assignment rules"? It can be missing from the page layout or if you're inserting Cases via API you can specify a header / DML option. Maybe try with ...


5

No need for a trigger. You can do this directly from the case layout page. Edit the case layout that you want to have this box checked by default, and click Layout Properties. You will see a 'Case Assignment Checkbox' section with two checkboxes, the first to show on the edit page, and the second is to chekc it by default. Check the box that you want ...


5

I have tried this and found that I can get it to both work and to fail. Let me explain how. I took the basic principle as the OP; A single Case Assignment Rule, assigning to a queue with the criteria ISPICKVAL(Type, 'Other') A simple test class to test assignment rules both on and off. I modified the test case to be a little clearer but the principle is ...


5

This can be done You only get control before assignment rules run in before/after triggers so, you need to do the following Option 1 (assumes you may want to keep some assignment rules) Create a new assignment rule that assigns to a queue called 'Pending Assignment Q'. Make it first in the sequence of rules Create a custom Boolean field on Case called ...


4

Since validation rules can only have one message to present to the user, I think combining validation rules is a bad idea. If you are hitting your limit of validation rules on the object you can try asking Salesforce to increase that limit or you will need to turn to using triggers.


4

What you're looking for is called "round robin" assignment. 1) If you want to custom build it, you can find the approach on a similar question that I've answered for Cases and Accounts here. You would need to do the same thing for the users and leads. 2) There is an app called "Round Robin Record Assignment" on the appexchange, I personally haven't tried ...


4

You want to use the DmlOptions.EmailHeader Class for this. The class has 3 properties that can send or suppress system emails. The property you are looking for is triggerUserEmail. Here is an example of how you would use it Database.DMLOptions options = new Database.DMLOptions(); //THE PROPERTY YOU ARE LOOKING FOR options.EmailHeader.triggerUserEmail =...


4

Assignment rules are metadata, and cannot be altered directly via Apex (cropredy's answer is a workable alternative). As far as I know, they can only be altered via the Metadata API, which you also can't use directly via Apex. You should be able to access the Metadata API by using FinancialForce's Apex Metadata API Wrapper. In the end, this is a horribly ...


4

You can look for the options to use Omni-Channel for lead assignment. Use Omni-Channel to create work items from Salesforce records and route them to the most qualified, available agents in your organization. That’s right: You can automatically route most Salesforce objects in a Salesforce Queue—including cases, leads, chats, and SOS video calls—to your ...


4

I think dmo.assignmentRuleHeader.useDefaultRule = false will not stop you firing the rule. Refer DmlOptions.AssignmentRuleHeader Class DmlOptions.AssignmentRuleHeader Properties assignmentRuleID: Specifies the ID of a specific assignment rule to run for the case or lead. The assignment rule can be active or inactive. useDefaultRule: If specified as true ...


4

1) Queue for a Custom Object is already created and added with few internal users. Now, when the records of the custom object is assigned to the Queue, how the members of the queue pick up the record from the queue and assign to themselves? I mean, where do they go and see the list of records in that queue and assign to themselves? In the List View, they ...


3

try adding the seeAllData annotation to your test method @isTest(seeAllData=true) static void test_mockIfAtAllPossible(){ }


3

When creating cases from a trigger, you can specify DMLOptions to prevent the assignment rules from firing. Something like this: trigger X on Y (after insert) { Case[] cases = new Case[0]; for(Y record: Trigger.new) { if(someCondition) { cases.add(new Case(...)); } } Database.DMLOptions options = new Database....


3

Here's what I found. There's a link to do this with apex programmatically, and you may need to call the assignmentRuleHeader class in an update trigger. From a standard UI, a user can trigger assignment rules by simply checking the "Assign using active assignment rules" checkbox under the Optional section. The problem arises when your app needs to ...


3

Unfortunately, it appears that is a current limitation for the process builder according to the idea here. Definitely go vote it up and maybe join the group that the PM suggested.


3

This can be done in two ways: 1) Using workflows: Make the workflow fire on only when the record is created. set the ownerid of case in the field update 2) in the flow itself you can set the ownerid based on your criteria


3

I won't necessarily say this is the best process but I have certainly seen this done (when OWD for Leads is not private) Keep your lead assignment as is For the sales rep X covering their own + the rep Y on leave's Leads ... create a custom List View, report, or dashboard that includes both the Leads owned by rep X plus the leads owned by rep Y. Have rep X ...


3

Normally, Lead assignment rules are triggered upon new lead, and, from the API (i.e. Marketo), Marketo must supply an AssignmentRuleHeader. If you want to reassign leads based on an update, then, as you know, in the UI, the user must manually tick the checkbox to apply assignment rules. The same holds true for any API client, the AssignmentRuleHeader would ...


3

I've solved this as follows Recognize that triggers run before assignment rules and E2C will run assignment rules. In before insert trigger, set custom field Bypass_Assignment_Rules__c to true for those use cases where assignment rules should be bypassed. Create assignment rule (at position 1) that takes any Case with Bypass_Assignment_Rules__c = true and ...


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

From the webservice class if you run this type of logic, it will enforce the Lead assignment rule. List<AssignmentRule> lstAssignmentRule = [SELECT id FROM AssignmentRule WHERE SobjectType = 'Lead' AND Active = true LIMIT 1]; AssignmentRule objAssignmentRule = new AssignmentRule(); Database.DMLOptions dmlOpts = new Database....


3

If you were using the SOAP API, the AssignmentRuleHeader is availiable in order include it in your HTTP call, but since you're using the REST API, then you have to enforce it manually in APEX. With the following code you can apply the rule in the webservice: Database.DMLOptions dmo = new Database.DMLOptions(); dmo.assignmentRuleHeader.useDefaultRule = true;...


3

Yes, go to the layout and click "layout properties" at the top and you should be able to set a default value.


3

I've solved related issues with a strategy like this: In before insert trigger; set a custom field Has_Been_Round_Robin_Assigned__c to FALSE In your lead assignment rules, the first rule checks the aforementioned custom field for false and assigns the Lead to a Queue called 'Pending Assignment' . Be sure to uncheck the email box on the right side of this ...


3

You can't properly schedule an action using either of the options you specified. The "no criteria" option will disable scheduled actions for "on create and update", and the "formula evaluates to true" option requires the "only when the specified changes are made to the record" option, which means that a simple formula like "true" will never trigger the ...


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