Trimming aow_processed table

If you are using workflows, you may notice that probably by far one of your largest table sizes is aow_processed. Looking at the rate of growth of this table compared to all the other tables is concerning. After a couple years, I could see this table being HUGE. Is there not a safe way to trim this table ocassionally? Many of the triggers for example could be for when modifications are made to cases. Many of those cases could be long closed. So record of the workflow being run on that case trigger is of no use.

Solutions?

Considering in large scale companies using SuiteCRM with lots of workflows, these tables could get HUGE.

No one?

We have a deployment that is being used for more than a year now, around 15 users and quite a few custom workflows.
There are actually two tables which grow very large aow_processed and aow_processed_aow_actions.
The current size of my tables are:

aow_processed - lines: 995.283 - size: 540Mb
aow_processed_aow_actions - lines: 995.631 - size: 536Mb

These tables always grow and never shrink(maybe when you delete related records they do - haven’t tried).

One day I wanted to see what happens if I empty these tables :wink: - so I created a copy of the entire application and emptied these tables. As soon as cron hit the scheduled tasks it started to execute all actions related to workflows - that is it started to send out tons mails about meetings created since the beginning of time and whatever was defined to be done in workflows.

So, as it is now, unless some changes are made to the core code, you should not touch these tables.

I also would like to find a solution to this but it is a complicated topic - we need in some way keep track what workflow has been executed on what record.

Maybe the easiest solution would be to implement an option in System setting with a time limit (say 3 months) and so:

  1. when executing workflows skip all records with modification time before that limit
  2. purge all records from these tables older than this limit

It definitely needs to be looked at.

Being the OP, obviously I agree.

One stance though is that these days, storage is cheap.

But on the other hand, on sites with heavy use of workflows, after a few years they size of these tables could be problematic if purely from a performance standpint.

I know I’m very late to the party here but just curious, was the “Run on” set to “new records” only or “all records”? i believe if we did the same for “new records” only then the workflows won’t get re-executed.

Good practise here if anyone is following this old thread… workflows that run on all records all the time can be deleted from the table because they will run again. Ones that repeat, in general can be deleted, because they will expectedly run again. If you have worklflows that run once per record, you have to be careful because if you delete it from the log, it WILL run again and you may not want it to.

I usually go through my workflows, get the workflow ID’s of ones that I know I can delete (as described above) then just select DB log records related to those WF ID’s. With a few SQL statements you can clean out alot.