Wednesday, 1 February 2017
Monday, 16 January 2017
The record couldn’t be saved because it failed to trigger a flow. A flow trigger failed tothe flow B000000DBl4. Flow messages: An unhandled fault has occurred this flow An unhandled fault has occurred processing the flow. Please contact your administrator more information. Contact your administrator help.
Option #1: Look into your debug log
: : ( )|WF_FLOW_ACTION_ERROR| L3B000000ChpG| B000000CgBk| executing flow: Create_and_Update_Opportunity_for_Provisioning_Order, FlowDefId: B000000CgBk, FlowVersionId: B000000DBl4 : : ( )|WF_FLOW_ACTION_ERROR_DETAIL| An unhandled fault has occurred in this flow An unhandled fault has occurred processing the flow. Please contact your system administrator more information. : : ( )|WF_FLOW_ACTION_END| L3B000000ChpG
Option #2: Use Workbench REST explorer to get the details
Option #3: URL hacking
Processes and Flows seems to have the same underlying technology, and this option will pull up either one in the Flow editor. This will help you to get the name of the component(flow/process builder). Note to edit Flow in Flow Designer and edit Processes in Process Builder only to avoid any confusion or unintended results. This is how you identify if it is a flow or process: Close the designer page and if you lands on process builder page, go to the process you noted down. If you are on the flow page, click to open the flow again.
Option #4: Search by Id under metadata type in Workbench
Info --> Metadata Types & Components --> FlowFlows Info --> Metadata Types & Components --> FlowDefinition Processes
Monday, 19 September 2016
Thursday, 4 August 2016
Use this URL to install the package into any organization:
Note: If you are installing into a sandbox organization you must replace the initial portion of the URL withhttp://test.salesforce.com
Wednesday, 27 July 2016
I am back with this blog on my initial analysis on “Active Workflow Rules limit exceeded” workaround. They(vis-à-vis the relevant important points) are enumerated below.
We have two options. They are:
Either follow #1* below; increase the limit to 300. Further new Workflow Rules/Actions to be accomplished through Process Builder highlighted in #2** below.
Identify which existing WF rules could be migrated to Process builder considering #2** below.
· #1* By default, each object (or entity) is limited to 50 Active Workflow Rules. If you need more, you can request an increase of up to 300 Active Workflow Rules.
· #2** Post Salesforce Summer ’16 Release Notes, Process Builder can execute multiple action groups at one time, giving you more ways to automate your business and manage everything in one place.
Now you can choose what happens after your process executes a specific action group. Should the process stop, or should it continue evaluating the next criteria in the process?
It’s up to you! Best of all, executing multiple action groups in a single process makes it easy to manage all of your processes for a given object, like a Case, in one place.
With this release, I think Salesforce is trying to encourage "One Process Builder Per Object" which is analogous to “One Trigger per Object” design pattern.
· Some important limits:
o Total number of criteria nodes in a process - 200
o Total number of criteria nodes that are evaluated and actions that are executed at runtime - 2,000
· Process Builder Design Considerations
o If you create processes to replace other setup entities, such as a workflow rule, or an Apex trigger, make sure you delete those entities when you activate the equivalent processes.
Otherwise, both workflow and processes will fire and cause unexpected results, such as overwritten records or redundant email messages.
o Actions are executed in the order in which they appear in the Process Builder.
o If any of the actions fail, the entire transaction fails and an error message displays.
· Process Builder Scheduled Actions Considerations
o If an action group contains scheduled actions, you can't continue evaluating the next criteria in your process after executing those actions.
o 2 ways as per my perspective:
§ First, create separate process builder for Scheduled Actions, OR
§ Second, keep the scheduled action in the last node of the same process builder so that there is no question of evaluating next criteria node.
· What more I did
o In my sandbox, I tried to validate if Process Builder has functions available to satisfy the existing Workflow rule criteria because there are certain limitations on usage of few functions in process builder.
· Next Step
o Identify which WF rules need to be migrated.
o To start creating a TEST Process Builder to see how does it behave(to find any unexpected behavior) and how we can accommodate/migrate most of the existing Workflow Rules into it.
Note: These are just a analysis report prepared w.r.t. SFDC Summer '16 release notes. Efforts have been made to simplify the concept.