Thanks to Susan Sparks who came up for the name for this talk at the 2015 NYC World Tour. And thanks to fellow MVP Chris Edwards (@Chris_SFDC) for his fabulous blog post for #NoCodeNovember aka #KnowCodeNovember
There is a heap of information about what Process Builder is, and how to use it. Use the resources on the right hand panel (start with Trailhead).
This is more about the why, rather than the how.
If you haven't looked at Process Builder in a while, take another look.
In the past little while there is a whole new world opened up to Salesforce admins - the ability to do custom development with clcks and not code.
Code is still valuable, but simple things like creating a new record, can now be done with code.
Many of the frustrations you had with workflows are taken away.
No more URL hacks - use Quick Actions instead.
Use a Sandbox
Know how to deploy processes to production
Know when to use Process Builder and when to use Flow, and then when to use Code.
Sketch out your process - yes, use pen and paper (or something like Google Docs or LucidChart if you must), or write it out as a story or a list of steps or do all three - whatever works.
Keep a documentation log as to all the automations that are applicable - eg one field update may now trigger a workflow, a process builder, a flow and some code - and they may not play well together. As and Admin you need to know exactly what happens when, even if it is in code.
Talk to your developers. The line is now blurred between admins and developers, and it will keep moving. Developers probably won't lead this discusssion, you will need to. Developers may not want to lose control - this is where you need to make an agreement about testing, documentation and deployment so crossovers don't happen. You two need to talk!
If you can use regular Workflows to do it, then use Workflows. Don't put actions into Process Builder for the sake of it.
Otherwise use Process Builder.
Then use Visual Flows.
Or see if there is an app on the Appexchange to do it.
If all other options are exhausted, then, and only then build custom code.
Or build custom code that is modular can be called or re-used by Process Builder
Also look at Quick Actions, and even rethink or challenge the business requirement.
~6 months later, go back and look at how it is working for the business, and make adjustments if necessary.
One limitation of the Mailchimp for Salesforce plugin is that when a user unsubscribes in Mailchimp, it does not update the Do Not Email field on the Contact. See the Example Process - Mailchimp Unsubscribe
If there are multiple quotes out for review, then update all to lost if one is marked as won.
Create an Opportunity to make a renewal sales call for an expiring membership.
When an Opportunity is won we need to do X steps to get the project up and running - things are always forgotten.
Update a Latest Comment field on the Contact when a post is made to the feed so you can report on it easily (will need some work to weed out the automated posts).
Post the contents of a field to the feed to keep a log of the value in that field as at today (eg a description field - there is no history tracking on description fields).
Post to a Chatter group or the manager's feed when an Opportunity is won.
Assign a Permission Set when a user is created with a particular role.
Automatically add a Lead or Contact to a Campaign by creating a Campaign Member.
Make Opportunity Team Members automatically follow the feed for that Opportunity, then unfollow 2 weeks after the Opportunity is won.
A record change on a parent record needs to fire off an email on a child record.
Post to a chatter group whenever a project overview is updated with a checkbox of Potential Case Study.
Clone a record and related records (or use the SuperClone app to do this).
Being able to quickly build out a scenario so we can try out some new functionality. For new processes there are always changes in the first few months as the process gets bedded-down in the organisation. It may be coded later, when the process is locked down, but declarative programming options allow us to be much more agile in our delivery of solutions.
It puts the admin in control - no more being hamstrung waiting for the budget to engage developers or developers to finish other work.
You can quickly get something up and running - even if it is just as a proof of concept.
Being able to go into an org and rebuild some old triggers into something that can be controled by the Admin in future. It is a great opportunity to ask if that trigger is still doing what it needs to do, and to document the processes.
Take 15 workflows and move them into one Process - Oh, and why are their 15 workflows? Maybe there is an easier way to do this?
Take a process that is currently manual and work out a way to do it with clicks (hint - it probably won't be just Process Builder - you will probably need to use ALL the declariative tools at your disposal).
Stops on the first true. Vote for it. (but there are others like it). Apparently coming soon - see below (#SafeHarbor).
No time-based worfklows list. Vote for it. (Look apparently they do show up in Paused Interviews, but I've never seen it work and why should I look in more than one place?).
You can't link to Processes. Eg for documentation. Vote for it. (Get used to this - there is many more examples of this in Lightning)
Can't reuse steps - eg updating the same field on each criteria, have to create it again and again. Vote for it.
As noted in the Spring '16 video:
More than one true! Wow, this will be so good. See above.
Trigger another Process - this may get confusing.
Process View Centre - see which objects have processes on them. This will be good.
If you haven't looked at Process Builder in a while, have another look.
If you haven't looked at Process Builder at all, then stop, go back and look at ALL the new features you have missed in the past two years, and start on Trailhead now!
Start with Trailhead.
Vote for ALL the ideas!
Think about a simple business processes that you want to be able to overhaul, and think about a few ways you can improve it.
Start to understand the role that Process Builder and Visual Workflow can have within your org.
Talk to your developer - what are some of the triggers that can be deprecated and replaced with Process Builder.
Go to your local User Group. And share your story when you do something cool. (Also contact me with your success stories please).
as a Salesforce Admin, for an organisation where Salesforce is the single source of the truth, your role has a significant impact on success of the organisation. Know your place in the organisation, know what the impact you have is. Use declarative programming tools like process builder to do some really cool stuff so that you can then move onto the next big project that will really rock your world, and make your organisation more of a success!
Go forth and ROCK YOUR WORLD with Process Builder!