That awesome feeling when you take that last leap to traverse a certain level #Ranger as the last adventure of 2017 . Thanks #SalesforceOhana @Trailhead for #SeizetheTrail quest. @SalesforceDevs @newdelhisfdcdug pic.twitter.com/Nr1taTPbJw— Sudhir Kumar (@sudhir_kumar_sf) December 15, 2017
A blog ^(my tweets) on Salesforce.com
Learning the cloud way...
Friday 15 December 2017
Finally a Trailhead Ranger Rank
Wednesday 1 February 2017
Reading thru the process builder error report
"This article is intended for the newbies in process builder troubleshooting"
In continuation to my previous post "Ways to identify your failed flow/process builder", this post will help beginners to identify the ways to understand the flow error report or even its debug logs.
I am referring to a sample process builder email report down below to read thru. I have added my comments to help you understand the jargon used in the report. Please /**Read between these asterisk-tags**/
Please note that this report lists the elements that the flow interview executed. This flow report is a beta feature.
Please note that this report lists the elements that the flow interview executed. This flow report is a beta feature.
So here goes the sample one with my comments and steps enumeration added:
To be continued..
Monday 16 January 2017
Ways to identify your failed flow/process builder
We would have seen this error while trying to save a record in our Salesforce instance. The information provided is very generic and little; it shows just the flow version id. It would have been strange for the people seeing this for the first time. I too had come across such situation and this is an effort to spreading the information out there.
The record couldn’t be saved because it failed to trigger a flow.
A flow trigger failed to execute the flow with version ID 3013B000000DBl4.
Flow error messages:
An unhandled fault has occurred in this flow
An unhandled fault has occurred while processing the flow.
Please contact your system administrator for more information.
Contact your administrator for help.
This post aims at outlining a few ways to identify which component is causing this error.
Option #1: Look into your debug log
Keep your developer console opened and try to save your record again. Search for the logs like below. You can get the flow/process builder name under "Error executing flow".
00:49:57.0 (80251134)|WF_FLOW_ACTION_ERROR|09L3B000000ChpG|3003B000000CgBk|
Error executing flow: Create_and_Update_Opportunity_for_Provisioning_Order,
FlowDefId: 3003B000000CgBk, FlowVersionId: 3013B000000DBl4
00:49:57.0 (80266593)|WF_FLOW_ACTION_ERROR_DETAIL|<b>An unhandled fault has occurred in this flow</b>
An unhandled fault has occurred while processing the flow.
Please contact your system administrator for more information.
00:49:57.0 (80340575)|WF_FLOW_ACTION_END|09L3B000000ChpG
Option #2: Use Workbench REST explorer to get the details
Go to Workbench --> Utilities --> REST Explorer and use GET with the below path to get the information: (/services/data/v37.0/tooling/sobjects/flow/{flowID})
For example; see the screen shot
Option #3: URL hacking
https://[instance].salesforce.com/designer/designer.apexp#Id=[id]
Replace [id] with the flow ID that is errored out and [instance] with your salesforce instance
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
Go to Workbench --> info --> Metadata Types & Components --< Choose "Flow" from the picklist --> click Expand All --> CTRL+F to find the Flow name and details by its Id.
You can find both flows and processes using Workbench:
Info --> Metadata Types & Components --> Flow for Flows
Info --> Metadata Types & Components --> FlowDefinition for Processes
Monday 19 September 2016
#TRAILHEADATHONWEEK @newdelhisfdcdug
#TRAILHEADATHONWEEK @newdelhisfdcdug
Congratulations to all the winners who made it to Top 5!!— Atul Gupta (@atul31gupta) September 19, 2016
Prizes will be announced soon!!#TrailheadathonWeek pic.twitter.com/WLnjonJbXU
Thursday 4 August 2016
Unmanaged package & GitHub repo to get LEX Opportunity progress bar inside Salesforce Classic
With reference to my previous post "Replicate Lightning Experience Opportunity Progress Bar into Salesforce Classic UI" , since people are asking for easy way to replicate this, I am going to provide an unmanaged package to help people get this beautiful view at a click away.
Step #1
XperienceProgressBarForSalesforceClassic
Version 1.3
Use this URL to install the package into any organization:
https://login.salesforce.com/packaging/installPackage.apexp?p0=04t90000000NOPH
Note: If you are installing into a sandbox organization you must replace the initial portion of the URL withhttp://test.salesforce.com
Step #2
Some post-installation steps are identified below to help you get going.
Step #3
After installation, edit your Opportunity page layout to add a one column Section with '.'(a dot) as its name just above detail section as shown in screen shot below.
Step #4
Step #5
Save your page layout to get the view as shown in this image.
Quite simple. Isn't it? :)
Note: This is designed exclusively for Opportunity stage field. However it can be tweaked to get it working for other objects as well.
Wednesday 27 July 2016
Active Workflow Rules limit exceeded? - Process Builder is the savior
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.
OR
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.
o
Meaning?
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.
Subscribe to:
Posts (Atom)