Yes, you can and should use constraints during initial creation and editing. I do this all the time.
The data does not magically appear in your backend. Do the operation in the same backend workflow as your initial API call. There’s no reason to not do it a the point of entry. Post the initial full workflow and someone can help you do this.
On this, database triggers can’t trigger other database triggers or themselves, so that’s not a necessary consideration. See here:
Triggers cannot kick of other triggers
A database event trigger cannot kick off a second triggers:
if data is modified by a workflow initiated by a trigger, Bubble does not check to see if those modifications are eligible for initiating other trigger events.
You can get around this by scheduling a separate custom event or API workflow from the original database trigger event workflow. Any database change made by this second workflow will trigger as expected.
This method will consume more workload
Also, while sometimes necessary, it should be used with caution, since it can easily set up a cascade or loop of workflows that can spend significant resources and possible lead to data corruption
Has to be done intentionally, at which point it’s very much on the user. I use A LOT of triggers in a big app, and it’s very far from being problematic because I use them to make small, tactical changes that would otherwise be a manual nightmare.
Unfortunately, don’t have the API call setup just yet as I just upload an Excel sheet containing all the original data in our database then I would just upload the small amount of entries or changes that would occur. Furthermore, waiting for Bubble support to get back to me about the overages so I can start using my app again. Currently, can’t do anything with the overage charge I’ve got.
Either way, if you upload CSV to the database or ingest data via an API call, you can modify the data on input and you don’t need to modify it once its in the database.
Something is definitely missing here.
Database triggers do need to be used with caution however, it’s one of the most effective ways to ensure data integrity and consistency as well as implement safety nets for edge cases. More often than not it is recommended to use them.
Can you post a specific use case? I believe you, but I wonder if there’s an alternative way to accomplish the same thing without them.
How would this be looking in terms of not making changes to the whole database?
Again can only test once my overages are sorted. Furthermore, once thats done will try to set it all up under the API Call workflow.
Update:
Hi everyone,
Just an update still waiting for Bubble support to get back to my case, as of yet there is no progress. Unfortunately, due to the overages the app has been taken down. I either have to pay $650 or when Bubble support gets back to me.
Important to get your strategy right. Remember that in the end of the day, Bubble controls everything. So you need to decide how important it is for your business and if you are comfortable to leave the key at the desk of Bubble so they can do as they please.
Do not forget that Bubble has its strengths and benefit but it depends on what you need and at which stage.
Those screen shots show you are searching the entire database and using extract with Regex which I’m not sure if that extract with regex causes extra WUs to be consumed than if you just fed the extracted value directly into the constraint (that means put the extracted value on a group on the page and reference that groups value in search constraint instead of doing the extract with regex on the search constraint itself).
The created date constraint of looking for things created 30 seconds before the current date or more basically means only records created within a 30 second period of time would be excluded from the search.
Also, when using DB triggers, you have the OPRID now is not OPRID before change, which means every single time you have a new routelink, that DB trigger is triggered because the routelink OPRID before is empty and after creation it is not empty, so by default a new routelink triggers this DB change. Better conditional will add an “and” operator to say “and OPRID before is not empty” so that only routelinks whose OPRID was Changed will trigger this DB trigger.
To be honest I would like this all resolved by Saturday but its looking bleak. I am wondering if there is a way to pay early so I can get my WU backs.
Issue is I have it working in the backend and have no idea how to refer to an element on the page when it doesn’t allow me in the backend.
Secondly, I was hoping that the search includes or only finds anything created in the last 30 seconds, as when the OPRID DB trigger occurs, it will only be importing 3-4 entries at most, and would want them to change those.
The issue I find is that when I change the data in the database automatically after the DB trigger, isn’t that a trigger in itself and changes the DB again and it loops?
Create a parameter for the backend workflow and when scheduling from the page, send the value as the parameter value
Change search constraint to include a second for the date, which is the opposite of the comparison you already have so as to basically create a ‘range’…normally you need a greater or equal to and a less than or equal to comparison on the same date so as to get a range of just the last 30 seconds.
the database trigger change will not cause another database trigger change…but from a different workflow making changes will trigger the database trigger change…what is important to get database trigger changes to work effectively is the right conditional to have it run ONLY when you want it to run. My suggestion previously of adding the “and” condition for ‘thing before change is empty’ helps make sure it only runs when the field value is changed and not also when first populated.
Thank you for this really helps me out. Will definitely give it a try once my overages/WU are sorted, which god knows when that will be. Hoping somehow I can pay early by Saturday so I can just get my WU back and the app back up and running as it’s been taken down right now. Will get back to you and everyone once it happens.
Hi everyone,
Just an update, thanks to the amazing Bubble Support Team, they will be waiving off the fee. Once they do, and my app is back online, I will be applying your suggestions and testing which one works best.
Thanks Bubble Support Team 
Hi everyone,
Bubble support has officially waived my fee for this one time and my app is back online! Wanted to thank the Bubble Support Team for all their help they have truly been wonderful. Special shoutout to Ryan for the support team for taking my case too.
In regards to my API Workflow:
This is what appears to be working well, as soon as I create an entry with an OPRID of Spin 1-7, it automatically changes that specific entry immediately to Spin only without the number, without taking up much workflow as its now not repeating looking through the whole db for the entries. Now to find a way to delete all but one of the duplicate Spins.
I wanted to say thanks to everyone here and their support, this community/forum has been amazing and wishing you all the best.
Sarrie
Congratulations ! 
