Q. A developer writes a trigger on the Account object on the before insert/update event that increments a count field. A workflow rule also increments the count field every time that an Account is created or updated. The field update in the workflow rule is configured to not re-evaluate workflow rules.
What is the value of the count field if an Account is inserted with an initial value of zero, assuming no other automation logic is implemented on the Account?
In order of execution, firstly trigger runs then workflow.
before update -1 count
workflow update – 1count
before update -1 count
After workflow update, before trigger will only run once so total count will be 3.
Q. Whenever case is created send email to case owner. How to do that?
We can do it using workflow.
Q. I have two workflow Rules and two fields F1 and F2.
When ever F1 is updated to value= 10, WF1 fires and updates F1 value to 20 and F2 value to 30
When ever F1 values= 20 there is another Workflow WF2 fires which will update F1 to 10 and F2 to 20
What will be the outcome of this Workflow rule.
• This scenario will cause recursive Workflow rule
• This will exhaust the governor limit and result in error
Q.Is it possible to delete the workflow when the workflow is having any pending time dependent actions?
No
Q. What is the use of re-evaluate workflow?
- If the field update changes the field’s value, all workflow rules on the associated object are re-evaluated. Any workflow rules whose criteria are met as a result of the field update will be triggered.
- If any of the triggered workflow rules result in another field update that’s also enabled for workflow rule re-evaluation, a domino effect occurs, and more workflow rules can be re-evaluated as a result of the newly-triggered field update. This cascade of workflow rule re-evaluation and triggering can happen up to five times after the initial field update that started it.
- Make sure that your workflow rules aren’t set up to create recursive loops. For example, if a field update for Rule1 triggers Rule2, and a field update for Rule2 triggers Rule1, the recursive triggers may cause your organization to exceed its limit for workflow time triggers per hour.
Example if field A=10 => Change it to field B = 100
If field B=100 => Change field A=10
- Only workflow rules on the same object as the initial field update will be re-evaluated and triggered.
- Only workflow rules that didn’t fire before will be retriggered.
- Cross-object workflow rules aren’t candidates for re-evaluation.
- Cross-object field updates that cause a field value to change don’t trigger workflow rule re-evaluation on the associated object.
- An approval process can specify a field update action that reevaluates workflow rules for the updated object. If, however, the re-evaluated workflow rules include a cross-object field update, those cross-object field updates are ignored.
- Time-dependent actions aren’t executed for a reevaluated workflow rule in the following situations:
- The reevaluated workflow rule’s immediate actions cause the record to no longer meet the workflow rule criteria.
- An Apex after trigger that is executed as a result of a workflow or approvals action causes the record to no longer meet the workflow rule criteria.
Q.How to avoid recursive workflow?
- For the workflow Evaluation Criteria if you choose created, and any time it’s edited to subsequently meet criteria option, we can avoid recursive workflow rules.
- If you don’t enable Re-evaluate Workflow Rules after Field Change checkbox in the Field Update of a workflow rule we can avoid.
- For example, suppose that for an opportunity record to meet the rule criteria, the opportunity probability must be greater than 50%. If you create an opportunity with a probability of 75%, the workflow rule runs. If you edit that opportunity by changing the probability to 25%, the edit doesn’t cause the rule to run. If you then edit that opportunity by changing the probability from 25% to 75%, the edit causes the rule to run. With this last edit, the rule runs, because the record is changed from not meeting the rule criteria to meeting the rule criteria.
Q.Define a Flow Trigger for Workflow (Pilot)
Create a flow trigger so that you can launch a flow from workflow rules. For example, your flow looks up and assigns the relevant entitlement for a case. Create a flow trigger to launch the flow whenever a case is created, so that all new cases are automatically set with a default entitlement.
Q.What is Cross-Object Field Updates?
For all custom objects and some standard objects, you can create actions where a change to a detail record updates a field on the related master record.
For example, in a custom recruiting application, create a workflow rule that sets the status of an application (the master object) to “Closed” when a candidate (the detail object) accepts the job. Or, for standard objects, create a rule to change the status of a case from “Awaiting Customer Response“ to “In Progress” when a customer adds a case comment.
Q.What happens if workflow rule has time trigger set to past?
If a workflow rule has a time trigger set for a time in the past, Salesforce queues the associated time-dependent actions to start executing within one hour. For example, if a workflow rule on opportunities is configured to update a field 7 days before the close date, and you create an opportunity record with the close date set to today, Salesforce starts to process the field update within an hour after you create the opportunity.
Q.What happens if we change the rule criteria of time based workflow and updated rule don’t match the criteria?
Time-dependent actions remain in the workflow queue only as long as the workflow rule criteria are still valid. If a record no longer matches the rule criteria, Salesforce removes the time-dependent actions queued for that record.
Q.What are Limitations of Time Based workflow?
- Time triggers don’t support minutes or seconds.
- Time triggers can’t reference the following:
- DATE or DATETIME fields containing automatically derived functions, such as TODAY or NOW.
- Formula fields that include related-object merge fields.
- Salesforce limits the number of time triggers an organization can execute per hour. If an organization exceeds the limits for its Edition, Salesforce defers the execution of the additional time triggers to the next hour.
- If time-based workflow actions exist in the queue, you can’t add or remove time triggers or edit trigger dates without deleting the actions first. Because the deleted records can’t be restored, carefully consider the implications of editing the workflow rules before you proceed.
- You also can’t add or remove time triggers if:
- The workflow rule is active.
- The workflow rule is deactivated, but has pending actions in the queue.
- The workflow rule evaluation criteria is set to Evaluate the rule when a record is: created, and every time it’s edited.
- The workflow rule is included in a package.
Q. What are the Time-Dependent Workflow Limitations ?
Time triggers don’t support minutes or seconds.
Time triggers can’t reference the following:
• DATE or DATETIME fields containing automatically derived functions, such as TODAY or NOW.
• Formula fields that include related-object merge fields.
Q.When cannot you add or remove time trigger from workflow?
You can’t add or remove time triggers if:
• The workflow rule is active.
• The workflow rule is deactivated but has pending actions in the queue.
• The workflow rule evaluation criteria are set to Evaluate the rule when a record is: created, and every time it’s edited.
• The workflow rule is included in a package
Q. We have a Time Based Workflow and there is Action scheduled to be executed. If we Deactivate the workflow, Scheduled actions will be removed from queue or not?:
Even after deactivation of workflow, its action will be active in queue.
Q. We have Time Based Workflow and there is action scheduled to be executed. Can we delete that workflow?
If a workflow has any pending time dependent action, then we cannot delete the workflow.
Q. How to clear the Time based workflow action queue?
1. Make criteria false for all those records.
2. Navigate to Set up -> Monitoring -> Time Based Workflow, search for scheduled actions and remove from queue.
Q. When the Add Time Trigger button is unavailable?
The evaluation criteria are set to Evaluate the rule when a record is: created, and every time it’s edited.
The rule is activated.
The rule is deactivated but has pending actions in the workflow queue.
Trigger vs Workflow?
Salesforce Workflow:
- It is an automated process that can shoot an action which is based on evaluation and rule criteria.
- Performing DML operations in the workflow is not possible.
- You can obtain a workflow over an object.
- You can’t create a query from the database.
Salesforce Trigger:
- It is a piece of code which is executed either before or after a record is updated or inserted.
- More than 15 DML operations can be used in a single trigger.
- More than 20 SOQLs can be used from the database in a trigger.
- You can access triggers across an object and related to that object.
Limitations of Workflows That Triggers in Salesforce Overcome
- Workflows cannot create or update a separate object.
- You can’t reference certain fields when using workflows.
- You will not have your workflow doing more than just field updates and emails.
PROCESS BUILDER
Q. Points to consider when calling apex class from process builder?
- Only Classes that have @InvocableMethod annotation will be listed for selection. Use this annotation at the method level.
- The method should be static and public or global.
- A class can only have one method which has this annotation.
- Can’t use other annotations with @InvocableMethod annotation.
- Invocable methods can have only one parameter. These methods can accept only a list of primitive data types or list-of-lists of the primitive data types
Q.Explain Recursion – Allow process to evaluate a record multiple times in a single save operation?
When you add objects to your process, you can choose to evaluate a record multiple times in a single save operation.
If you choose this option, the process can evaluate the same record up to five additional times in a single save operation. It might reevaluate the record because a process, workflow rule, or flow updated the record in the same save operation. When a record is reevaluated, the process uses the most recent values for that record.
For example, your sales review process includes multiple steps, approvals, notifications, and fields that need to be updated. Some of these changes may be part of your process, or they may be managed by other workflow rules or flows in your org. If you let the process reevaluate a record multiple times in a single save operation, you can manage and evaluate all of these changes—even changes from other processes—in a single save operation in your process.
Example:
In process builder = if b=100 =>change c= 200
In flow if a-10 => b =100
Initial Value :b, c =>0 a=10
B has no value so process builder is bypass
Flow has a=10 so b becomes 100
Now Process builder already ran but we have checkbox true-so it verifies.
Now as b = 100, so c becomes 200
Q.Do you want to execute the actions only when specified changes are made to the record?
It is equal to Created or edited to subsequently match the criteria of workflow
Q.What should be the condition we need to specify in process builder to specify schedule actions?
Below are 2 conditions:
Only when record is created
When record is created or edited and while define criteria select the checkbox for below setting
Q.Is it possible to edit the process once it is activated?
No, You need to clone and while cloning you can create new process or create new version.
Q.What can be done using Process Builder?
Creating records: This will allow you to create a new record and create different field values for a record.
Updating records: You can update one or more records which are somehow related to the record that started the process. This can be done either by manually entering records or by using the records from a related record.
Posting on Chatter: Process Builder allows you to post on Chatter for sharing any information to any user.
Quick action: If you already have global actions or objects, within Salesforce, you can use Quick action to use them in any other record.
Launch/trigger the flow: It is possible for you to launch the flow from your process to automate different processes.
Submitting the record automatically for approval: The record which started your process can be submitted. Any other record can’t be automatically submitted.
Call/trigger Apex code: You can invoke an Apex code which you have already written within Salesforce.
Invoking another process: This action will actually invoke a process to another process.
Q.Whenever there is any change into Contact Email update custom field of Associated Account with the latest Changes into the account email.
We will go for process builder because using workflow we cannot update related record other than master detail
Q .Update custom field of Account Object?
Workflow is the right automation tool for the above scenario
Q.Update all related case and Contacts with the same email of account whenever account email changed.
Process Builder will be the right tool to use here as we need to update all contacts and cases there may be more than 1 and Process Builder allows you to do the same.
Q.Count no of child records related to master record into Lookup relation.
You have to go for the custom solution using Apex Trigger.
Q. What DML operations can be done using Process builder
1. Process Builders cannot handle before DML It executes after a record has been created or updated. Whereas Apex triggers can handle both before and after DML operations.
2. Process Builder cannot handle delete and undelete DML. Whereas Apex triggers can handle all DML operations.
Q.Process Builder Vs Apex Trigger?
| Process Builder | Apex triggers |
| You cannot handle before DML operation.It executes only after a record has been updated or created. | You can handle both before and after DML operations. |
| You cannot handle deleting and undelete DML. | You can handle all DML operations. |
| An error reported in Process Builder is more generic which makes it difficult to find the origin of the error. | Exception handling can be made more specific. |
| You cannot update unrelated records. | You can update unrelated records. |
| You have to use Process Builder in conjunction with flows to create custom record sharing. | Share records with more complex criteria than sharing Rules Permits. |
| You cannot create email templates that pull information from multiple records and objects combined, solely by using Process Builder. | You can create email templates that pull information from multiple records and objects (combined with Visualforce). |
Q.What is Mixed DML Operation and how to solve Mixed DML Operation Error in Process Builder in Salesforce?
If any user wants to perform DML operation on setup and non-setup object in the same transaction then there is a chance of generating “Mixed DML Operation” error.
Example:
ABC company give a requirement to their employees, if any employee joins our company then we will create a user in user object and as well as we will auto create a sick leave, casual leave, earn leave in there leave balance object which is a custom object. If an employee will perform this scenario then an employee will get Mixed DML Operation error.
Solution:
As we know we can not use DML operation on the setup and non-setup object in the same transaction then we have to separate it by time dependent trigger
Q.How to call Future methods from Process Builder?
To call Future methods from Process Builder, call the future method from the invocable method.
Q.What are the things which we can not do with process builder in Salesforce?
- Deleting Records (Alternative: Flows/Apex Trigger )
- Outbound Message (Alternative: Workflow/Apex Trigger)
- Cloning a record (Alternative: Apex Trigger)
- Updating unrelated records (Alternative: Flows/Apex Trigger)
Q. What kind of related records can we update using process builder in Salesforce?
- Parent Records (Master or Lookup)
- Child Records (Master or Lookup)
