I add the custom event after/before each step in the workflows during debugging. I then copy the expressions into the logger which creates a record with text data when the workflow runs. (I have it in a custom event so they get created in a consistent way so my other auto delete logic works).

It’s a great way to get visibility on workflows as I can break down the steps as much as I need to figure out why I get the result I get.

Usually I start with 1 log for each custom workflow so I can see if a workflow isn’t running - then I’ll narrow down and add more logs until I find the root issue. It’s also a great way to check for looping and things happening out of order.

I generally only use it on test side debugging but occasionally I add it to live side - although for live side I normally have a change history data type that I log into for various datas.

For data that is shared across many parts of the app (ie files, change history etc) I don’t use data fields to link the data, instead I use a generic text field and map the datas ID into it. This way you don’t end up with 50 fields on something like “files” or “videos” when they have to be linked to 50 different datas.

For instance:
File data structure:
name, file url, size, type, for_id (text to hold the unique id of the thing it links to)

Then I just use the search for:
search for files where for_id = this things unique ID.

1 Like