SugarBPM is a powerful feature in SugarCRM and, for most customers, the centerpiece of their automation strategy. However, when it comes to storage management, SugarBPM can have a huge impact on your instance’s database size.
To help you avoid unnecessary database bloat, I’ve put together this guide on best practices for designing SugarBPM Process Definitions with storage efficiency in mind.
Why Does SugarBPM Consume So Much Storage?
Let’s take a very simple process definition:
- Start Event
- Change Field Action
- End Event
- Two flow lines connecting them
So, five elements in total.
Now, when a record triggers and runs through this process, it will log at least 7 rows to the database, across three tables:
- pmse_inbox – A single row as the parent entry for the process.
- pmse_bpm_thread – At least one row.
- pmse_bpm_flow – Five rows, one for each step in the process.
Now, imagine this process triggers 10,000 times. That simple process would add at least 70,000 rows to your database!
So, What Can You Do?
You need these automations—of course you do. You wouldn’t have implemented them otherwise. My goal isn’t to discourage you from using SugarBPM, but to help you apply best practices that keep storage accumulation to a minimum.
Some logical questions you might ask are:
- How essential is this stored data for SugarBPM to work?
- What does this stored data do for me once the process is completed?
For the most part, this data is not essential—but before you rush to delete it, we need to discuss one key reason why some of it must be kept.
Best Practice #1: Avoid Using "First Update" in Start Events
If any of your Start Events are configured with "First Update", Sugar needs to retain at least one row in the pmse_bpm_flow table for each record that triggered the process. This is how it remembers that the process has already been triggered for that record—so it doesn’t trigger again.
Recommendation: Avoid using "First Update." Instead, set your Start Event to "All Updates" and use criteria to prevent unnecessary triggers.
Personally? I recommend never using First Update at all.
Best Practice #2: Retain Only Relevant Process History
Process Management provides a ListView of processes—whether they are In Progress or Completed.
This is where all that stored historical data comes into play. But let’s be real—how often do you actually need to look up a completed process from a year ago? Five years ago? Probably never.
The only reason to keep this content is for:
In Progress processes – You don’t want to delete these. Recent history – In case you need to investigate an issue.
Everything else? Purge it.
Recommendation: Keep In Progress processes, maintain a rolling month of history, and purge the rest regularly.
Best Practice #3: Use Data Archiver to Purge Old SugarBPM Data
One of the most common questions I get is: “How do I regularly purge this data?”
Answer: Data Archiver.
Set up an Active Archiver to Hard Delete from pmse_Inbox, with filters such as:
- Status is NOT "In Progress"
- Date Modified is more than 30 days ago
With the scheduler running at a frequency that makes sense for your system, your SugarBPM history will be kept to the necessary, useful minimum.
Caution: Data Archiver does NOT have filters to protect against "First Update" usage. (See Best Practice #1)
Best Practice #4: Eliminate Redundant Process Triggers
If a record triggers a process but doesn’t result in a meaningful change, that’s a huge red flag that your Start Event criteria aren’t restrictive enough.
A common mistake is designing processes where records can go from Start Event to End Event without actually doing anything.
Does your process include paths that don’t trigger any actions or Send Message Events? Can a record pass through Wait, Receive Message Events, and Gateways without meaningful change?
If yes, then that process shouldn’t be triggering in the first place.
Recommendation: Use Start Event criteria to prevent unnecessary process triggers.
Best Practice #5: Prevent Redundant Field Updates
Here’s a sneaky way processes waste storage—they update a field to a value it already has.
Example:
A Change Field action sets Type = Customer. If your Start Event doesn’t include a condition ensuring Type ≠ Customer, then this process will run even when it doesn’t need to.
Recommendation: Always ensure Start Event criteria prevent redundant updates.
This principle applies even in more complex scenarios—if you’re changing six fields, make sure at least one of those changes is actually necessary before triggering the process.
Best Practice #6: Choose the Right Automation Tool
SugarBPM isn’t always the best choice for automation. Unlike other methods, it logs every step permanently, which can lead to unnecessary database growth.
Consider these lighter-weight alternatives:
Workflow Management – Best for simple, two-step automations (conditions → actions/alerts). Calculated Fields – Ideal when the system should always define a value (e.g., read-only calculated fields). Logic Hooks & Custom Schedulers – Require PHP knowledge but offer quiet, efficient automation without unnecessary logging.
Recommendation: Think critically before defaulting to SugarBPM. Sometimes, another automation method is the better option.
Final Thoughts
By applying these best practices, you can:
Optimize SugarBPM usage Prevent unnecessary database growth Ensure automations remain efficient and scalable
If you’re finding that your database is growing faster than expected, take a step back and evaluate:
- Are you using First Update?
- Are processes triggering unnecessarily?
- Is SugarBPM the best tool for the job?
With a strategic approach, you can keep your automations powerful, without the storage headaches.
What are your experiences with SugarBPM storage management? Share your thoughts in the comments!
