A talk for the Admin Theatre at Sydney World Tour March 2017.

This page is available at bit.ly/ClicksCode

When embarking on the journey of transforming your business by using Salesforce you will need to customise Salesforce to work for you. There aren't that many businesses out there that are all about selling Widgets to B2B customers using a model sales process, and it's not like Salesforce is just about CRM and sales anyway - it's to run your whole business (almost).

With customisation, there are two broad choices, and a multitude of choices within those two areas - Clicks or Code. Clicks are using the declarative tools including Workflow, Process Builder and Flow. Code is diving into Triggers, Apex Classes and custom Lightning Components. As with anything worth doing, there are choices and trade-offs between the two, and people will argue black and blue that you should never touch Flows or Process Builder - but then they are probably developers. On top of this, before you delve into spending a heap of money on code always think of the code that others have already built and put on the Appexchange. Do not reinvent the wheel.

The worst thing any organisation starting on Salesforce can do is to either dive into only Clicks or only Code. (Well clicks only may be a great idea for a very simple business, but only code is never a good option). Organisations that have a few C# or Java developers and send them along to a Salesforce Developer training course for 5 days and expect them to transform their new Salesforce purchase into a workable solution (yes, I have seen this, and no, it doesn't work).

There is a definite need for a balance between Clicks and Code - but where is the line? As with most complex problems, the answer is - it depends.

Declarative Options

When you have a very good understanding of a business problem to solve, it can be a great idea to build out that solution using declarative tools so you can refine the scope to give to the developer. You will most likely find that there are complexities that you had not thought through. After doing this process, you may keep the declarative customisations or use this as the basis of a scope for coding the solution to solidify it in the org.

Building solutions in declarative tools can help you build up your knowledge and vocabulary to work with developers in a much more collaborative way. It's not us vs them, it's us all working together to develop a solution for the business need.

If you have a good developer they should know enough about declarative tools to push back on you and say, I don't need to code that, you can do that in Process Builder. Or you together might come up with a process plus some invocable apex to do the job. But both of you need to understand that there are apps or patterns or blog posts out there that can maybe do what you want to do without reinventing the wheel. Eg take a look at the Declarative Lookup Rollup Summaries tool or Process Builder Blocks - a sample of invocable processes that can be called by Process Builder.

Process Builder Issues

So very easy to cause an error see Process Builder Errors and Weirdness
No good error handling, especially around validation rules.
Only the last person to edit the flow gets the error messages.
You can change a field name without any warning and it will break your process builder so bad you have to change the field names back in order to fix it.
You can deactivate an invocable process which will break your process that calls it, and you won't know about it until you try and run it.

Ways to Avoid Issues

Ensure all existing data meets the criteria for any new validation rules.
Limit the amount of validation rules you have (good rule anyway).

Code

If you are going to do code you have to commit to it, commit to maintaining it; 3 times per year, as new features and ways of coding are released. (Well, it is similar for declarative options too. New features will come out that will mean there are better ways to do things). Code written 5 years ago is probably not written to coding standards we have today, but it probably still works.

The Rules

I've broken all these rules, so now it's time for me to write them down so I don't break them again.

Don't mix Process Builder, Flows, Workflows and Triggers in the same transaction. How do you know you have done this? Well probably after you get Process Builder errors on every update or create.
If your Flow is more than a handful of DML operations, or can't neatly fit on one screen, invest in having it coded.
If your Process Builder extends a managed package, then think about having it coded.
Do time based workflows in Workflows not PB or Flows. It is impossible to see which records are in a waiting state in PB or Flows.
If you need extensive error handling on your process, you are going to need code. There is no error handling that can alert users in a meaningful way, on Process Builder or Flow.
If you need a lot of messaging back to the user, you are going to need code.
If it's anything to do with Integration or REST APIs, then unless you are using one of the very expensive third party integration tools, you are going to need code.
- Outbound messages, which can be done in Workflow are good up to a point, but then become very limiting.
- There is a new feature, in Beta - a wizard to help create links to external services.
If you've got many versions (let's say more than 50) of your Flow or Process Builder, it may be time to start thinking about coding).
6 months after implementing a flow or Process Builder, re-think it - is it mission critical - then think about moving it to code.

When to use declarative development options:

If you are just creating one or a few records on an update of a record (be sure to test for bulkification though).
If you are just updating a lookup value (things you can not do with workflows).
If you need to automatically kick off an approval process.
If you have different things that happen based on different values of the same field (eg where you would normally need to do multiple workflows).

When to use a combination of clicks and code:

When you need to do something via code but quite infrequently - use invocable apex code that you can invoke via Process Builder.
When you have a great developer who can build a simple invocable process that you can use with Process Builder.

Some additional notes:

Always test any customisations before and after a new Salesforce release. That's a given.
Always build flows and processes in Sandbox then deploy them to Production (yes, I know, deployment of Process Builder and Flows is kinda hard).
Run your test classes often, to make sure that you haven't broken anything that code relies on, or your future deployments will become a nightmare.
Know what's in code and what's in declarative tools. In the perfect scenario you will have it all documented.
Know what the managed packages in your org do - especially if you have tried to extend the managed package with any declarative options or code.
As an Admin, when you click a button, know what it does. You should know this even more than your developer knows this.

The Line

So where to draw the line between Clicks and Code. Well that is up to you, and depends on your business and what sort of budget you have to implement the system that is going to transform your business. There is no definitive right way, Start with Clicks, but know that you may want to move to Code when Salesforce becomes more of a mission critical part of your business. I would say never start with Code because if you are just starting with Salesforce you will never know enough about how you and your business will use Salesforce to get the benefit out of spending that money up front.

Remember, this advice is aimed squarely at small to medium businesses or NFP that does not have a team of dedicated, experienced Salesforce developers on staff.

Browser not supported