#process builder

For those who have had the unfortunate experience of performing a data-load into Salesforce, only to discover the rascally after-effects of having to answer to those who have received unwanted notifications, you are very aware of how incredulous this can be. If the result of this further included end-customers receiving emails (be it test or actual context) then perhaps ‘incredulous’ would likely be replaced by ‘agitation’ or perhaps ‘bedlam’. Through many an admin’s journey, there has been at least one instance of this occurring, and when it occurs (even on a small scale), it is akin to the lesson we learned as kids of putting our hand on a hot stove-top. When it does happen, we likely don’t repeat the same thing again as the lesson has been learned, but if you’ve never had the (dis)pleasure of such an occurrence, there are some simple rules of the road to follow in which to avoid such a calamity.

Perform the work in your Test Environment Salesforce has provided the Sandbox Environment for a reason, so why not use it for its intended purpose? Agreed, the data may not be exactly as what’s on your production version (unless a refresh has just been done), but the peace of mind that it gives you when performing data-loads can drastically reduce the amount of issues

Ensure that the Deliverability option is set to ‘System Emails Only’ or ‘No Access’ If you are performing a data load which does not require a resulting email alert, then turn off the deliverability. However, if you need to see the email alert results of your data-load, use ‘dummy data’ with email addresses that are meant for testing purposes.

Pro-Tip: Consider using a disposable email service such as TempMail or GuerrillaMail which are ideal for testing while at the same time providing a secure, spam-averse experience.

Review your Process Builder, Workflow and Validation Rules which are associated with the Object you are performing the data-load on BEFORE the onset of an Insert / Upsert action. Easier said than done, perhaps… but in reality it takes only a few minutes and unless there are new rules which are being developed during your data-load you need only perform this task once.

Utilize the ‘Power of ’Minimum’ When you have your final CSV file ready to test, instead of loading all of the records in at once, do a ‘Save-As’ and create a second Test-File by removing all of the rows except for the first. If there are any errors (and if your load includes an email address, make sure it’s your own) then the damage will be insignificant in comparison to a full load of hundreds (or thousands) of records. Just this one step, which takes only seconds to prepare may be one of the best defence mechanisms you can take to eliminate anguish.

As a Salesforce professional admin or developer, you are always dealing with tight deadlines and understandably so, things can happen… more so when you’re in a crunch and time is a luxury you can’t afford. If you are a seasoned admin, you’ll know the ramifications of all outcomes when performing a data-load and are always ‘on duty’ when the prospect of a load is required. The same ‘checklist of items’ refrain will be running over and over again in your mind prior to a change / addition of data into your environment. For the greenhorn however, there is no such experience-level that has been realized (yet), and if this is your first time to the party, take a tip from the veterans who have been at this juncture just too many times as they will plead with you to mechanically go through the steps initially so as to learn how these mistakes can be avoided altogether. Remember, Salesforce doesn’t have a conscience and will do whatever you tell it to, and like a tempest, can inflict destruction at the most inconvenient times. It’s no different really than any other life-lesson which if a sense of preparedness and practice are paramount, the result will be that of cool heads and an intact ego.

Like a massive storm that suddenly came out of nowhere, you have just been given a seemingly impossible task to be delivered in record time. While given the ‘guts’ of the project without no concrete details, you feel in your bones (having been at this stage before) what will come next in rapid succession, which is your answer to the inevitable question “When can you deliver it?” While many projects have come and gone in your tenure as Salesforce developer, there comes along a specific task that you know all eyes are on, due to the size and scope, forcing you to make the decision to:

Develop a solution built for the short-term, or

Consign yourself to admitting a long-haul approach, expecting a 3x (or more) timeline

Choose Your Appeasement Wisely It is during these times that you must vision the end goal much further down the line than what presently exists as an idea, and if you believe this will be a long-lasting application that will be utilized for years to come (especially by major stakeholders) then the just path will surely be one of the Salesman over the ‘Order-Taker’. This means you must gird your loins and assume that you will be asked the reason for the longer-than-expected timeline. You may think to yourself when you chose to be a developer that you never signed-up to be a sales professional, but honing this skill set is not only encouraged in your role, but predicted if you are to rise above the median role so dominant in this space. But when you think about it, there are many decisions that you have made to get to where you are today, and odds are that a vast majority of them (such as landing the gig that you have now) was a direct link to how you ‘sold’ yourself. The other criteria to be cognizant of is your ability to realize delayed gratification, as choosing the high road will always demand that you think of the reward or accolades down the road for a job well done (and well-deserved) instead of a quick fix. While we all enjoy the satisfaction of a professionally-delivered project, by and large most small victories are seldom remembered and celebrated quickly with the next task being already discussed just a few minutes thereafter. Whereas, things that take time, and are built to last will not be forgotten as easily and will live on in the minds of the stakeholders who will recommend you for larger and more challenging pursuits. Considering all of this, think back to the task you have been asked to deliver and choose your path. If the future application is to be something truly unique and ‘killer’, just assume that there will be increased levels of toil and long hours with many versions and thinking outside of the box, not only for you, but for the team you assemble to make this a reality. A Blaze Of Glory In contrast with taking the long way, the option of course still exists to choose the rapid solution. Taking this path may stand a good chance of being recognized for completing the task in record time, but only you will know the answer to it being a true ‘job well done’. Remember that if the ask is not a complex undertaking, it may not fall under the classification of a ‘project’, and as such your just rewards will still hold true because quality applies to tasks both big and small. That being said, if a large project is deliberately masqueraded at the outset of being a straight-forward affair, what you don’t want to happen is to sabotage your effort to serve the vanity of a hastened delivery time. Yes, doing this may have short-term benefits, but the after-effects further on would likely be a certainty akin to a weak link in the armor.

Sometimes it is standard-issue to be bold when you know the outcome that others may not have envisioned… due to your experience because you know better, and though it may not be easy to question, or defy convention, if your conviction level is strong, your audience will understand the importance of all of this in time. Go through a few revisions of this, and there will come a time when there will be less questions, and more ‘realistic’ timelines based on your past performance of delivering a quality product. After all, you didn’t stick to a single Salesforce methodology, but persevered when the new options became available and adapted. Rather than remaining stagnant, you struggled and put the time in. If you didn’t you’d still be only using 1.0 Workflow Rules, as opposed to utilizing the modern Process Builder and Flows. The Time Saver That Never Fails P5, mateys… Proper Planning Prevents Poor Performance. This applies to scouting, just as it does to development if you but only plan ahead. Add to this a dose of self-reliance and making decisions based on YOUR knowledge (and not perceived ‘experts’) and you’ve been given everything you need to complete a successful project. While on the surface, it may sound easy, 9 times out of 10 it is not, but it’s simple, which means you have the ability to achieve it. Next to the manifesto or project management style (Agile, Waterfall or Six Sigma) the most important part of delivering any project is the initial planning and seeing the end-result and then working backwards before spending your (and your team’s) valuable time. Choosing to do this in a consultative manner will give you the best opportunity of seeing (and removing) the obstacles beforehand, and then initiating development in a phased approach. Of course there will be unknown obstacles that will show up at the most inconvenient times and at various timelines in your development cycle, but this will be dwarfed by the larger amount of issues which would be an order of magnitude larger than if you didn’t prepare ahead of time. As such, tacking these pesky debugging sessions should be a minor inconvenience, especially if you have your eyes set on the final goal, and not wavering from the hard work and dedication to get to the finish line. Remember, the only sure way of failing is to quit by choosing the path of least resistance. If you have done your due diligence, have secured the right members of your team to pull it off, and know in your gut that the benefits will be felt throughout the organization… your enthusiasm should be at an all time high, with the long-term benefits of being asked to deliver more challenging, and satisfying projects.

We always hesitate to make change to our lovable assets but change in life will always brings a better future. The same applicable while  Migrating From Workflow to Process Builder. Here are few advantages process builder brings over existing workflow.

We can merge multiple workflow to a one process builder for a single object.

If we have one process builder per object we can assure order of execution but if we have multiple workflow define per object we can’t guarantee the order of execution.

Updating cross object records either child or parents are simplified regardless of master detail or lookup relationship.

We can invoke flow from process builder if required to do more complex logic.

Even though outbound message not supported by process builder but still we can make callout by invoking apex method from process builder. We can write any complex callout logic inside apex method not limited to only XML we can do so for JSON as well.

Overview 

The Process Builder is a new workflow tool from spring release 15 that promises you to easily automate your business processes by providing a powerful and user-friendly visual representation of your process as you build it. The Process Builder’s simple and powerful design which not only creates, updates records, send emails, Call a Flow, Post to Chatter and Submit for approval but also calls apex class in order to achieve requirements which cant be done by any of the above.

What are the classes which can be called from the process builder ?

To answer this question @InvocableMethod comes into play. A process builder can call only apex classes which implemented @InvocableMethod annotation for a static method in it.