...
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 DEV451 a Salesforce Developer training course for 5 days and expect them to transform their new Salesforce platform purchase into a workable solution (yes, I have seen this, and no, it doesn't work).
...
- 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.
- Prior to Spring '17 Invocable processes won't allow you to uninstall ANY APPS.
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).
...
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 no not written to coding standards we have today, but it probably still works.
...
- 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:
...
- 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 kick off with a process builder 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.