A user can go into their account and type out the name of a project in a field, and then hit ‘Create’. The workflow on that button should trigger a ‘create a thing’ across 10 different databases (each databases represents a form which the user will fill out when populating information about their project later on).
Now, the databases all share the ‘project name field’ and are linked through a central database. So for example, Project Name, which occurs in each of the 10 databases also appear in a Central Database but the datatype of the Project Name fields in the Central Database all link back to their respective databases.
I think it’s for the above reason I cannot actually use ‘Create a thing’ because the expression turns red, such as below:
Approach 1
The ‘trial’ is the project name and the input its pointing to is what the user would’ve populated with the name. This field is linked back to the central database which is why I don’t think its accepting this expression.
Approach 2
I tried another way, using ‘result of step X’, but when I went through the debugger, the rows were being created in the database, but the name wasn’t being carried from the central database to the others.
I can create the name successfully in the Central Database field as that field isn’t linked to anything. However, the debugger showing the name field blank for the subsequent databases
So, the goal here for me is to be able to create a thing ‘project name’ in each of the databases once the user clicks create. I thought the first option would work, but doesn’t and I think it’s something to do with the expression and not respecting how the relationship between fields have been set-up. However, the second option of using the data from the previous step also isn’t actually passing on the name for the subsequent steps to use in their database creation.
Yes, there are as many datatypes as there are databases pretty much. Every datatype that needs to be linked is featured in the central database as a datatype under a name such as ‘Project Name_DatatypeX’.
So when they click the create button, you would want to do “Create a thing” then create your central datatype, then have 10 more “create a thing” steps, one for each of your other data types. Then for each of the “create a thing” steps set your central datatype field to the Result of step 1.
Yes, so at the moment I have create a thing for the central database and there’s no issue there. However, ‘creating a thing’ for the other data types simply result in the red expression I have pasted in my first post, and I’m not sure why. I assumed this was because I was trying to create a thing for a field that was linked with the central database. Any insight into what I’m doing wrong here would be appreciated.
Then for each of the “create a thing” steps set your central datatype field to the Result of step 1.
Can you elaborate on your second point. Why the Result of step 1 needed?
When you say it goes red, that means take a look at the type for the field you’re trying to set, and what you’re feeding it. If it’s a text type, then it’s going to be red if you are trying to feed it something else that isn’t text.
Check my editor link and go to the workflow on the create button, this is what I described if I am understanding correctly. When it creates type #1 and type #2, it also set their “Central” type to my step 1 so it has a link to its central type.
Then take a look at the data types tab to see why none of it is red for me
Also It might be worth it to think do you need all 10 datatypes? Or can they be consolidated into 1 datatype but be differentiated with a “category” field? (If they share a lot of common fields)
Thank you @tylerboodman for taking the time to build this - it has worked for me and I’ve implemented this into my app. It didn’t take me long as I was half way there with the ‘result of step 1’ - I was distracted with the ‘more’ option that appears after this initial expression and started expanding the expression which resulted the project name not being carried across the other databases. I’m get to do more testing but so far I’ve checked the app data and can see each database populating with the project name (which wasn’t happening before).
I also had a list under the user’s profile where in a dropdown they’re able to select the project they want to ‘load’ and view. I got this working by adding in an additional step as part of the same workflow to add the project to the users list too, again using the result of step 1 option.
If you don’t mind, since you know the set-up I’ve got in place already, I want to extend this to also remove the a new project the user may want to delete - so basically the reverse of what we’ve implemented so far so a workflow that removes the project from all databases. This will also help me testing as every time I create a new project to test, I need to go into each database and delete the new entry as to not bloat the app.
I’m thinking that a ‘search for’ expression will be needed here where I can say ‘If dropdown value is X, delete thing’. And then in the same way using the ‘Result of step 1’ option, I can carry out the deletion across the other databases. Would that be the correct approach?
To answer your question on the number of datatypes. There’s actually closer to 14 or 15 datatypes (I used 10 for simplicity in my original post). Each datatype corresponds with a form the user fills out for the project so data is very much compartmentalized in this way. There might be scope to potentially trim 2 or 3 datatypes at the most, but they’re all very different to each other so nesting some datatypes under others might make it a bit more difficult to remember how some datatypes are under others, but then some have their own databases. I decided to have ‘slimmer’ databases but slightly more of them.
Do you have access to backend workflows (aka a paid plan)? You can use database triggers so when a the central datatype is deleted it triggers a search of all your 15 types and deletes any with that central project.
Check the editor link again, and click on where you would change pages, but click “Backend workflows” and see the database trigger there. It has a strict constraint so if the central project Before Change “exists” and after the change it doesn’t “exist” then that means it was deleted and it performs each search to delete
So all you do is on your front end make a button that deletes the central project and Bubble will do the rest in the background
I have a paid plan, but the first tier. Just checked mine and can’t see I have access to backend workflows sadly.
However…
I’m playing around with it working in the normal workflows and have made some progress. I’ve discovered I may need to go back to front - so I need to start deleting all the subsidiary datatypes first, and then the last step will be the central datatype to delete. Reason is if I start with the central datatype, the other datatypes don’t know what to look for because the name was anchored to the central name, which was deleted in the first step - so I ended up with all tables having rows intact with empty name fields. Working back to front is delete the rows properly, but haven’t finished compiling the full workflows yet.
Sorry forgot to mention go to the Settings menu, and go to API tab, and check the “Enable Workflow API and backend workflows” box
Yes exactly, however even if you deleted all the child types first, then your last step of your workflow was delete the central, there’s no promising that those are done in that order and I’ve seen it where the last step actually completes before the 1st step even starts. So the backend way is much more bulletproof because as you can see when it searches for the child types to delete it says “Before change” so you have a perfect reference of your central datatype before it was deleted
OK - I’ve activated the backend workflows, and its showing up now.
I have copied your expressions into my backend workflow, substituting my datatypes in. My button will delete the ‘central’ project name, but the one datatype I specified (just to test first) in the backend workflow doesn’t seem to trigger its deletion. The row remains there, but the name of the project disappears (as expected because the central anchor has been deleted).
Here is my workflow for the button to delete the central project name (this works fine). It’s saying delete the project’s with the name that matches what’s in the dropdown field:
Trying to workout where I’m going wrong here. In my head the deletion first occurs at basic trial information of the project name, and because this change is triggered, Bubble then looks for the same name project to delete in AESI, but do you think it doesn’t delete the row because it can’t find the name (because it was already deleted centrally)? A but like in my post above about having to start back to front by delete all child data types first? That’s my only thinking as to why its not working.
Thanks for your help on this, it all looks like it’s working! Still creating things and deleting them and checking through the databases to ensure its working as intended.
I’ve implemented the API workflow and adapted it for my app. The only thing I don’t quite understand is why the references are listed as 1, 2, 3, 4… is there any significance to this at all? I’ve not use API workflows at all so simply copied your example but still getting to grips with the mechanics behind what is happening. It looks like in the normal workflow the numbers are corresponding with the databases and field that needs to be searched for, and when found, deleted via the API instruction.
It also looks like I can’t see the flow of events via the debugger like I can with a traditional workflow?
Those are just arbitrary parameter names so they can be referenced from the front end to backend. You can rename them but in your delete actions you’ll have to pick the new reference.
Correct this is technically a backend workflow now, so it’s all happening server-side. So you are gathering all the “things” you want to send to the backend (by doing all the searches) then just sending everything to the backend to be deleted. In the logs menu you’ll see those delete actions happening
At some point you actually might want to move your “create” workflow to the backend as well because if a user hits create then closes out of the browser they could close out before it finished creating all 15 things. Once it’s schedule from the front end it runs in the background separate from the user’ browser
Yes I was thinking about that regarding the create function. I’ve got a hang of how the backend workflows work now and it should be easy enough to do the reverse for the create later.
Thanks again for guiding me through this, learnt a handful of new things and saved lots of time completing this over the past couple of days.
I’ve updated the editor to show the functionality of checking if the name already exists and I moved the create functionality to the backend.
Notice the create button has two workflows on it, one with the condition where it searches for any with the same name, if the count is 0 then it continues the create process, if the count is > 0 then it displays the red text and focuses the input again. And note the warning text “Visible on page load” is unchecked so it doesn’t default showing
