SugarBPM and Database Storage: Best Practices

RE: SugarBPM and Database Storage: Best Practices

Patrick McQueen — Mon, 19 May 2025 17:22:13 GMT

This custom SELECT query, which can be run in the Advanced Reports feature of the application, can provide you the ID number for all process definitions containing a first update start event:

SELECT prj_id FROM `pmse_bpm_event_definition` WHERE evn_type = 'START' AND evn_params LIKE '%updated%';

The ID numbers provided by this query can be added to the following URL to navigate you to the process definition's design canvas in your instance (also change to your domain to the beginning of the URL):

example.sugarondemand.com/#pmse_Project/<id>/layout/designer

Regards,
Patrick McQueen

RE: SugarBPM and Database Storage: Best Practices

Patrick McQueen — Mon, 19 May 2025 16:56:21 GMT

Hi Luke Ridgway ,

Thank you for indicating how the response you got from support did not align with what I've written about here. I apologize for that confusion. Over the year since you received that communication, we have provided additional training around Data Archiver to ensure consistency in our communication.

The rows of the pmse_bpm_flow table, which is most often the table consuming the most storage space in regard to SugarBPM, can be indirectly targeted as part of a collection of BPM tables when using Data Archiver.

Regarding the comments about Workflow Management:
At this time, there is not an initiative to remove Workflow Management from the application. It is a more veteran feature than SugarBPM and is an as robust in its feature set. I can offer some advantages in some use cases, which is my motive for mentioning it above.
My advice is to use SugarBPM as your primary source of automation within the application, and to be aware of the capabilities of Workflow Management in the event that employing it for a scenario serves you effectively.

Regards,
Patrick McQueen

RE: SugarBPM and Database Storage: Best Practices

Luke Ridgway — Mon, 19 May 2025 15:40:07 GMT

Hello again Patrick McQueen ,

Don't suppose you know if there's a way to filter, or to query the Process Definitions to reveal which indeed have a Start Event of 'First Update'?

I was thinking custom query perhaps?

That'd be a great time saver too - thanks in advance.

RE: SugarBPM and Database Storage: Best Practices

Luke Ridgway — Thu, 15 May 2025 15:20:49 GMT

Agreed, this is an amazing post - thank you Patrick McQueen !

I have also logged myself a task to schedule-in looking through our PD's using first update and then will definitley be using data archiver.

We previosly got up to a few million rows in that table. I contacted support who suggested that they can clear out that table for us - we removed everying older than a month and our storage dropped by about 3.7GB !!

This is discussed in this post: RE: Clean audit tables?

I quote the support team in my case saying:
"There is no way via the UI to delete data from a pmse_bpm table."

But in here it seems we can? Am I mixing up the tables from this post and the other post? Apologies if so.

But also in there Frédéric Rinaldi raised a good point of caution about the process getting triggered again. I guess that relates to the start events using first update too.

Workflow

Same question from me too: I thought workflow was legacy and being removed so years ago I moved all that functionality we had into BPM... it even had a warning on the screen to say dont use it.

Maybe Sugar could pick a lane? 😉

Also just to link folk here towards your other equally ace (kind of related) post for the File System Storage too:
RE: Reducing file storage consumption

Thank you again,
Luke.

RE: SugarBPM and Database Storage: Best Practices

Bud Hartley — Fri, 31 Jan 2025 20:21:06 GMT

WOW Patrick! This is GREAT! I'll be looking into all of the BPM processes I have running.

As an aside, I recall the time years ago when we were told that the Workflow Management function was being discontinued and we needed to migrate to BPM. Obviously Workflow Management hasn't been removed. I have a number of processes that simply send a notice of a change to affected users, or send alerts for an unusual change that should be checked. I'm thinking those should be moved back to Workflow Management where they were originally since we don't need the audit trail of the alert being sent.