So I have designed my workflow to set a slug for each record in my database:
Right now, it will create a slug if it is a new record, but how do I update the slug using the workflow when the record updates?
So I have designed my workflow to set a slug for each record in my database:
Right now, it will create a slug if it is a new record, but how do I update the slug using the workflow when the record updates?
The same way. It is one action for creating/modifying/deleting the slug
I would recommend going into the Backend Workflows and* creating a “Database Trigger Event”.
Anytime time the record is updated, you can run the “Set a thing’s slug” action automaitcally. Super hands off.
Hope that helps.
@dbevan Are you saying I could move my “Set a thing’s slug” actions into a trigger event in the backend workflow?
Exactly. So when you’re first creating the Event, set the Event’s slug just like you have in your screenshot.
Your process for updating* the Event’s slug should be hands off. That’s why you create a Trigger Event on the backend workflows.
The condition should be something like:
If the Event name BEFORE the change IS NOT the Event name AFTER the change, then run this workflow.
Then in that workflow, you’ll have that exact same “Set a thing’s slug” action.
@boston85719 So right now, I have the following settings in my "“Set a thing’s slug”:
Are you saying to create another one, but this time the Slug field should say “Result of step 2 (Make change to E…)'s Event Name”?
Ah, ok. Let me give that a shot.
Thank you.
Whatever workflow series of actions you have in place to make changes to the thing, simply put a workflow action to set the things slug. Unless you want to pay for the $130/month plan to make use of the backend workflow trigger function that has been recommended. I’m not 100% sure if Bubble still restricts access to the backend workflows for database trigger changes, but last I looked they do, so I avoid unnecessarily increasing my monthly costs.
When I would make use of a database change backend trigger is only if I am planning on making changes to a thing in multiple areas of the app, but in all honesty, in the 5 years I’ve been building on Bubble full time, I’ve never really bothered to increase my monthly costs just for that one feature, and instead opt to really simply add another workflow action in the series of actions I am already having to build out anyway.
Thank you for letting me know. I am new to Bubble and currently using the free version to test out whether it would work for my needs. The last 3 weeks has been quite a learning experience. I would be willing to upgrade to the $30/mo Personal Plan, but I did not realize that it would not support backend workflow.
That plan does support backend workflows, but there are 3 types of backend workflows. The database trigger change is the type that I do not believe you can access with the $30/plan.
If you build your app to work on the free plan, then once ready to launch you will need to only upgrade to the $30/month plan…if you are going to build your app to include features only available on paid plans, you will need to upgrade to those plans while building, before you may be ready to launch.
I highly recommend avoiding any features that are only available on paid plans while you are building. Once your app gains traction and there is a need to upgrade, that is when I would upgrade.
Yes the Personal plan gets database triggers
Thanks for the advice.
Right now, I hope to stay with the $30/mo plan. The reason I am building a custom app is because the existing out-of-the-box apps out there have way too many features that we do not need or want. I think if we do reach the point when we need to upgrade, we might consider those other existing platforms.
In terms of the solutions provided, I did set up a backend workflow, but I have also followed your suggestion too. I have to test it out yet because I found out something else I need to do before that, but if I understand you correctly, I added another “Set a thing’s slug” action like so:
I think that’s what you mean…?
Yes, but make sure on the step 3 and step 4 to add the conditional to reflect the same as the conditionals in step 1 and step 2 to ensure the slug is set properly.
I can’t see the conditionals in step 1 and step 2, but I assume there is a chance that the step 1 of create will always interfere with step 2 for modify…usually if my create workflow action has a conditional to only run if a thing doesn’t exist, but I also need a modify if the thing does exist, I put the modify first, so as to avoid the potential that the create action is run because something didn’t exist and then after it is created (ie: comes to existence) the step 2 is triggered because step 1 created and brought into existence the thing.
For the most part, I personally prefer to avoid this issues, by having separate triggers with the conditionals rather than a single trigger with the actions having the conditionals. So you may want to separate the create and slug from the modify and slug via two separate triggers with the conditionals from your step 1 and step 2 attributed to the triggers. It also helps reduce the need to use the same conditional on multiple actions, and instead only need the conditional on the trigger.
So I don’t see a Conditional tab when I click on the steps/actions themselves, but I have set Step 1 and Step 3 to “Only When Parent group’s Event is empty”, and Step 2 and Step 4 to “Only When Parent group’s Event is not empty”…
Do this, don’t try to mix actions together with a bunch of the same conditionals, just copy/paste the workflow, put the conditional on each workflow directly, then the actions don’t need any conditionals.
Or just go the database trigger route so the slug is always updated automatically
This topic was automatically closed after 70 days. New replies are no longer allowed.