Force.com follows an event driven process automation model

Events trigger workflow actions in the Force.com platform. Examples of events could be

  1. Record created
  2. Field updated to meet criteria
  3. Submit/approve/reject
  4. Schedule
  5. Upstream process

 

Based on these events, the actions could be

  1. Create record
  2. Update field
  3. Send eMail
  4. Post to chatter
  5. Outbound SOAP message
  6. Call Apex
  7. Call flow

How do you define which actions should occur when an event happens?

You have two choices – programmatic and declarative. Programmatically you can create Apex triggers to fire when events happen. Declaratively you can use workflow tools to fire up actions when events happen. In this section we shall look at the declarative workflow approach

A quick look at Force.com workflow tools

 workflow

Apart from these tools, you can of course use custom code (Apex triggers) to catch events and take actions.

What is Process Builder?

Process Builder is the nex-gen tool for creating complex processes in Force.com. As you see in the diagram, Using Process Builder combines the functions of the existing rules and approvals in one tool set. Another difference is that the Process Builder is a GUI WYSIWYG tool – you can define very complex processes using MS VISO like design surface.

This not only makes the creation easy; it also means that any changes can be done very easily also. One big advantage of the easy WYSIWYG design process is that if any of your business processes change, you can easily change your application flows.

Process Builder vs. Coding

Process Builder’s goal is to minimize the need for custom code. As an example, more actions are now possible in Process Builder – e.g. if a record is inserted, you can create a chatter post- something like this was possibly only through Apex coding earlier. The Process Builder is in a state of continuous enhancement, making coding even less necessary.

There will be many instances where you do need to write custom code. For example in the case of integration with existing systems – say if an account record is created in Force.com and you need trigger an account record creation in your MS GP database. In this case you could define a trigger to fire whenever a record is inserted in the account object, which calls an Apex class which in turn sends the record to MS GP database to be inserted there. Of course there are multiple ways of accomplishing it and you can even set up an outbound workflow rule for something simple like this.

Process Builder vs. .NET

Within .NET – as in Force.com – you have many choices for the tooling to create workflows. Windows Workflow Foundation, BPEL, custom C# code and third party utilities.

A key difference to remember is that in Force.com to share data with other execution contexts you have to use the
database (objects). This paradigm actually simplifies the process creation as you shall realize when you start modelling your use cases in Process Builder.

Beyond Tooling

However, the biggest difference between Process Builder and .NET workflows has nothing to do with tools. In the Force.com platform, user entitlements, security, data objects and visual layouts are tightly integrated. To reference any of these – and more – elements within your Process Builder all you have to do is select these elements from LOVs. Even when writing custom code for complex workflows in Force.com, all you need to do is use reference these elements easily in your program through their API names.

This is unlike .NET applications where you have to create your data bindings, access control and manage other elements of the design. .NEt has powerful tools – however in Force.com, the platform’s unified metadata takes tou beyond what’s possible with tools.