Business Process Management on Salesforce.com
This article is for all of my fellow Salesforce architects who never want to debug another trigger ever again.
Prior to jumping into the Salesforce deep-end of the pool more than 15 years ago I was desperately trying to solve problems in my corporate role… responsible for all of the business and operational support systems for a Fortune 100 communications company. In other words I was trying to clean up all of the messes of the company whose enterprise architecture looked like a Frankenstein monster of legacy systems, duplicate customer records, and in-movable concepts such as “mainframe” or “AS400”.
I was introduced to an interesting suite of software, Business Process Management (BPM), the likes of which have somewhat been replaced by Jira, Asana, and countless other apps. But the core concepts of BPM were intriguing and impressive when trying to solve long running business processes that spanned numerous departments, systems, and user personas. In my completely unscientific opinion I would say that Salesforce.com single handedly killed most of the BPM software in the market about 15 years ago.
Fast forward 15 years.
This week I have spent days and days trying to debug a Case trigger in Salesforce that makes my head want to break.
I apologize again to all of my die-hard Salesforce fans out there that are proud of themselves for memorizing the order of operations. Do you know who DOESN’T care about order of operations? Every customer that I ever met who just wants their software to work, their systems to be allowed to evolve without penalty, and honestly don’t care if the solution is configuration or code. They would prefer not to be bothered honestly.
I propose a theory…
Well designed software trumps administrators making ad-hoc changes in production using drag-and-drop tools whose debugging solutions makes programmers crave early retirement.
Salesforce systems are just NOT scalable over time. They decay due to a lack of standards, rotating consultants, multiple technologies (apex, workflow, assignment rules, sharing rules, process builder, flow, omnistudio…) and the list is getting longer. Does anyone ACTUALLY think this is the way to build a scalable system at this point in 2024?
In order to facilitate never having to debug a Case trigger ever again, I am happy to introduce the Business Process Management plugin for the Reactforce Enterprise Backend and Portal. This plugin will be the backbone workflow and process engine for all of the apps I ever build again.
So what does it do?
Define Business Process Versions
- The BPM process provides the swimlane instruction for each process, along with any SLAs or KPIs that are interesting to track.
- As a task moves through a process it will track metrics like: “How long did this process take from beginning to end?”, “What happened in the process that took the most time?”
- What queue should a task be assigned to upon creation of this process?
- What should happen upon completion of the process? (Easily daisy chain long running processes)
Define “Smart” Queues
- A queue is similar to an asana board or a jira project. Any “task” can be placed in a queue.
- The task in a queue can have any status, but will always be in either a Waiting, Working, Completed, or Exception state. Each of these metrics is tracked for each task and summarized for the queue, including the time spent in each state. (SLAs anyone?)
- Each queue has multiple SLAs that can be enforced: how many tasks can you have in this queue? What is the goal time by which the task would be in a Working state? What is the goal time by which the task should be Completed?
- Who has visibility to the queue? The queue visibility is based upon corresponding skills associated with the different users.
- You can define warnings on the queue if a task is at risk for not reaching working or complete status in time.
Define automation steps
The system has synchronous and asynchronous hooks at each transition of the process, queue, or status. This allows completely decoupling your case trigger into specific automation points to help you organize your case automations (or really any object that requires a queuing capability).
The following synchronous event hooks exist and can be defined at the process, queue, or task level. These hooks can execute apex via the callable interface or can execute a flow.
- beforeProcessCreate
- beforeProcessEdit
- beforeProcessCompletion
- beforeProcessDelete
- beforeTaskCreate
- beforeTaskEdit
- beforeTaskDelete
- beforeQueueChange
- beforeTaskStatusChange
- beforeQueueStateChange
The following asynchronous event hooks exist and can be defined at the process, queue, or task level. These hooks can execute execute an asynchronous function (create a platform event, execute an async worker, etc)
- afterProcessCreate
- afterProcessEdit
- afterProcessComplete
- afterProcessDelete
- afterTaskCreate
- afterTaskEdit
- afterTaskDelete
- afterQueueChange
- afterTaskStatusChange
- afterQueueStateChange
By building the logic design directly into the process, you are able to decouple the complexity of your SObject triggers into scalable event hooks that make sense.
Given all of the async functionality already is built into the existing libraries for asynchronous processing, you have nothing to fear as each activity can be fully logged and tracked at each step of the process. The dynamic automation hooks are built directly into the system allowing you to easily organize and evolve complex processes.
Another important feature of the BPM engine is that each task can be assigned to either a human or a system automation. You can create a state machine ENTIRELY for a machine process to track any long running async processes.
The system is built API first, as a business process management engine. Every function of the system is accessible via a simple REST api that makes system automation a breeze.
Because the system was designed with Reactforce in mind, you can assign a task to anyone, both salesforce users and non-salesforce users alike. This opens your company back up to enterprise wide solutions that were previously unavailable due to Salesforce’s aggressive named user licensing model.
In summary… if you put Asana, Amazon SQS, Apex, Flow, a UML loving business process analyst, and a cost-saving CFO into a blender you would come out with the Business Process Management Plugin. You will love building systems on top of this process engine and I promise your debugging days will no longer be filled with existential dread.
If you would like early access to the BPM engine or its related Task Management system email me direct: greg@cloudpremise.com. Until then… have fun debugging your next case trigger!
