[SalesForce] difference between Process builder’s submit for approval and Approval processes

Approval processes route a record to one or more approvers, specifying the steps necessary for a record to be approved, and who must approve it at each step.

In a typical approval process (what you're calling a "static" approval process), the approvers at each step are explicitly specified in each step approval process. You have a little flexibility -- for example, you can have the submitter choose the approver manually, or you can automatically assign it to the submitter's or record owner's manager, or to a queue -- but there's a limited pool of people who can be approvers.

Dynamic approval routing allows you to specify the approvers for each record using User lookup fields on the record requiring approval. The fields are populated using Apex, using data from a special custom object (the "approval matrix") that contains all the information needed to route the record. The approval process then uses the values in the lookup field, rather than the limited pool of users available in the so-called static process. This provides more flexibility: you could route to different people based on region or some other criteria related to the record, rather than having to write multiple static approval processes in order to perform the same functionality.

The steps for dynamic approval routing are:

1. Create lookup fields on the object being approved.
2. Create a custom object that will be used as an approval matrix.
3. Populate the approval matrix.
4. Create Apex code to fill in the lookup fields on the record, from the approval matrix.
5. Create or update an approval process to utilize the new lookup fields.

For example: suppose you have a position object and there are 3 levels of approvers. You need to route the record to different approvers based on the department and pay grade. You would:

1. Add custom lookup fields (to User) on the Position object, called Approver 1, Approver 2, and Approver 3.
2. Create an approval matrix object that stores all the fields used in routing: pay grade, department, and lookup fields to the User object for each approver.
3. Create the approval matrix records. For position, one might route records with the department of Engineering to high-level Engineering managers as approvers, whereas the department of Sales would have high-level Sales managers as the approvers.
4. Use an Apex trigger to populate the lookup fields on the Position record when the record is created, based on the values in the approval matrix.
5. On the approval process, in the approval steps, set the Assigned Approver to the appropriate lookup field on the record (Approver 1, Approver 2, and Approver 3).

As you can see this is more complex and requires Apex, but it can be powerful if you have complex and changing routing requirements. One other point to note is that while users require Customize Application in order to customize an approval process, the approval matrix object is just a regular custom object with the same CRUD and sharing possibilities as any other object, so you could allow non-admins to change the approvers.

Additional documentation/examples that may be helpful: - Approval Process Overview (Salesforce Help & Training) - Using a Matrix-Based Dynamic Approval Process (Force.com Cookbook) - Force.com Dynamic Approval Routing (Salesforce Developers)

A pretty complete overview with examples of which automation tool to be used in which case can be found here.

In short, you can do everything you can do with workflows using process builder as well, except for sending outbound messages with point&click. With process builder, you can also update all child records starting from the parent record, which is not possible with workflows (only vice versa is possible using cross object field updates). I've heard rumors that process builder will replace workflows in the future, which seems a logical step to take for sfdc.