to execute SQL queries you need to access the SQL server you have, I don’t think there is functionality to do that from the UI
as a workaround, you could use workflow to loop over all modules and delete all their records
I’m not sure how to do it but I think it’s possible
Thanks for this. How would I write the expression in the “Function” block in the workflow to delete all records in my “Leads” module?
As far as SQL related shenanigans go we’ve prepared a few snippets here but please do be careful with this especially if such work is new to you. We ususally recommend performing a DB backup before any such larger destructive operation.
Alternativelly, instead of deleting the data, you could set the
deleted_at column to
NOW() to perform a soft delete. The query changes to an update, but the condition remains the same.
You’ll need to loop through the records and delete them one after another; the workflow would look something like this:
The iterator is for compose records and the function is delete record.
If you have a lot of data to delete and you’re comfortable with it, the direct DB interaction would be by far the easiest.
If not, write a quick workflow like @munawir suggested, or use the bulk delete option by selecting the records you wish to delete.
I want to do it via workflow so I can understand how it works. Thanks for the diagram. What are teh details I need to complete in each block? ie: How do I tell it to delete all records in my Lead module?
I highly recommend you go through the docs especially the workflows, automation, and low-code platform developer guide sections.
As far as the original question goes, this is how I’ve done it for the built-in CRM app we provide…
Make sure to adjust it to your needs and be careful not to delete things you might want to keep.
If you’re new to this a safety DB backup never hurt anyone.
The trigger config here doesn’t really matter; I used some onManual event so that I can run it from the workflow editor.
The iterator type has to be
The module handle is found in the module editor screen, next to the module name.
The namespace handle is found in the namespace editor screen, next to the namespace title. Alternativelly, you can locate it in the URL address. For example in
http://localhost:18083/compose/ns/crm/admin/modules the namespace handle is
crm – the bit after
lead result target is just a variable name.
The function type has to be
Compose record delete.
record argument has to be the variable we used earlier (
lead in my case).
So nothing goes into the “query” section in the iteration, just the Module and Namespace?
Depends; my example deletes all records from the
If you want to limit this to just specific records, then you’ll need to add a query.
If you’re not sure, you can replace the delete record function step with some log/prompt step to see what all records are going to be deleted.
Got this error when I ran it…on teh right hand side.
Open up the configurator for the iterator – make sure that the handles are not expressions (notice a little checkbox thing to switch between an expression and constant)
i found what you meant and it was ticked. I have unticked it now, ran it and it failed with status code 504.
also this error cam e a bit later:
504 would indicate that something was probably misconfigured on the server end; can you interact with Corteza via the Low-Code app fine?
401 would tell that the credentials are no longer valid; if you refresh the page it should resolve.
Yes, the low code app works fine. It looked like it was working as it was thinking for a while…then this happened:
There are no leads now, but the records are still there. It’s like it has just deleted the text from the records and left the blank records there.
Hi @BenjaminDover, perhaps I’m shooting in the dark here, but is it possible this is somehow related to the pagination? From the screenshot, I’d assume you increased the number of records to 5000 per page and perhaps that’s too much data to digest at once. Can you decrease this number and see what happens?
Someone’s been eating their carrots…
I do not recommand to use workflow to delete lot of data. If you have more than 1.000 records on your CRM you will get 501 error and corteza-server should crash.
As suggested it is not recommanded to use workflow, or you can use server-script in workflow it will be more optimized.
501 error doesn’t seem like it was caused by a workflow; can you elaborate further on how you got to that error?
check your server’s timeout configuration
Sorry my bad ! it’s 504, not 501.
I’ll prepare a workflow to demonstrate we can crash corteza easily with too much data and will provide server configuration.
By default I work with HC server too much oversized, then I try to reduce capacity, but in my case it’s crashing at the beginning, with HC configuration.
I would suggest you setup a local instance and test there to see if the issue is with Corteza or your server configs.
I’ve been running some quite heavy-duty workflows not so long ago and they went through without timing out.
There has however been a feature that would cause workflow execution to crash due to high memory consumption.
Workflow execution keeps a stack trace but it is a bit too verbose and coupled with long executing workflows, the memory consumption can be high.
2022.3.0 we’ve added a
WORKFLOW_STACK_TRACE_ENABLED which would allow you to disable stack traces.
If your instance crashes due to no more memory errors, you have the following options:
Disable the stack trace
Use the above
.env variable to disable stack traces; not ideal but is quite acceptable for some cases.
Split up the work
Utilize the messaging queues to have different workflows perform smaller subsets of work.
We don’t have much docs for how to do this, but the TL;DR of it is:
- in the admin panes, messaging queues; define a new queue where the consumer is set to event bus
- in workflow A, use a function step where the function is “queue message send”
- in workflow B, use a trigger with resource of “system queue” and event “on message”.