Documentation
...
| Tip | ||
|---|---|---|
| ||
I can not explain Process Builder or Flows well enough. Just go to https://rakeshistom.wordpress.com/learning-process-builder/ to see all about it. |
...
Overall Issues
- Can't do one overall Criteria - eg IF this is a particular type of Campaign, then all the other criteria relate to this.
- You have to add that Criteria to each node of the process.
UI
- It takes the whole screen up - you can't quickly get back to other areas of setup. Open it in a new tab.
- You can't open multiple processes in a new tab from the main process builder screen - this is because the click event on the process builder heading is javascript code, and not a hyperlink. This is annoying. But get used to it, the whole of the new Lightning Experience is this way.
Good Things
- Create a Chatter Post
- Create a Record
- Automate Publisher Actions
- Automate Flows
- Update Records
- Related Records - up the chain
- Related Records - update multiple records below the current record. (but I'm not sure how this would really work in practice).
...
- You can't change the object that the Process runs from after you create the process. But workflow rules are like that too.
Emails
- You can use only email alerts that are associated with the same object that the process is associated with. The record that started the process is used as the starting point for any merge fields that are used in the email alert. Similar to workflows.
Activating
- You can't activate a process unless it has at least one action on EVERY node.
- You can NOT activate a process if there are more than 50 Active workflow rules on that object already. Note: you can keep creating workflows if there are more than 50 workflows, but you will get stopped if you try to deploy a workflow from Sandbox, or activate a process. (See https://help.salesforce.com/apex/HTViewSolution?id=000181391&language=en_US).
...
| Info | ||
|---|---|---|
| ||
I want to enter values on the Contract that are stored on the Account. Default values from the account. One is the Primary Contact for that Account that the Contract is for - so that's a lookup value. Lookup values can now be set by Process Builder - Yay! So it should be easy, right? Wrong. The other defaults are picklist values - eg Contract Type and Contract Process I only want the defaults to be updated IF the Contract is not Activated yet, and IF the Account is changed. I don't want to override any values inadvertently that may have been changed from the default. It is not likely that the Account gets changed on a Contract, but you have to allow for this. So, my first criteria node (in pseudocode) is
Then my Immediate actions on that criteria are Update Record, set:
Now, I SHOULD be able to put in a third update here - update Primary Contact from Account.Primary Contact BUT we run into this issue. https://help.salesforce.com/apex/HTViewSolution?id=000212174&language=en_US - the Process Builder fails IF the Primary Contact on Account is blank. So, you would think, well, I will just add another criteria to my process to keep it all in the same process. Wrong. Yep, I did this - this is why I'm writing this example. Second criteria node
Now, let's think about this - we still don't want to set the primary contact on the Contract unless ALL those criteria are still true. HOWEVER, the process will NEVER get there because Process Builder is very dumb - it only handles TRUE/FALSE. After the first criteria node is executed it will ONLY execute the second criteria node IF the criteria in the first node is FALSE. No. I want to execute the process again (recursion) AND with the same criteria - just the one additional criteria. This help document comes into play https://help.salesforce.com/apex/HTViewHelpDoc?id=process_advanced_considerations.htm&language=en_US but I am not 100% sure I'm reading it right. "ISCHANGED always evaluates to false when a record is first created". Yes, I get that. I am also not changing the account in this (or any other) process, so I can be confident that ISCHANGED is correct for the first node, but I don't know whether the recursion on the process would mean that ISCHANGED will be true or false on the second node. But it doesn't matter because under no circumstances will anything get to the second node because I only want to do any of this stuff when ISCHANGED is true. So, my options are - create 2 processes both with the same criteria - Nope. Hard to maintain (and actually I want three or 4 lookup fields updated). So it's off to create a Flow for me!. Flows are going to contain all the logic in one place and be much easier to see the logic and build. |
...