Easiest way to create a page/URL from Inputs value?


I have an Input and Button than when pressed creates an entry in a field called ‘Team Name’ in the DB. (That part is all good)

I would then like to create a URL specific to them, ie; acme.com/team/team-name

How would I do this. Parameters? Have tried a few different ways but no success :frowning:

Also the user would not be logging in or anything like that, so how would I sent the correct data to the page without them actually been logged in?

Many thanks

I can half way accomplish it, check out the workflows here: link

And you can clean up the URL using the method from this post: link

Im still learning here as well, so excuse me if something in there is incorrect!

1 Like

Thanks will try that out. Looks pretty much what I need.

Have you been able to work out how you would then add a team member to that specific team? I have tried creating Workflow that adds ie; Dave Smith to Team Acme but I can’t get it to add to the entry it is just adding a completely new entry?

Not sure how you would make the connection?

I’m gonna have to figure that one out, I think I know, just have to put the pieces together

This is directly analogous to my discussion of a hypothetical /user/name page described in the forum reply linked below:

There’s a great deal of detail here that you wouldn’t need in your use case, but in brief the idea is that you create the /team page. (Its Name is “team”.)

When that page is loaded, you examine the “path” to extract any path part that’s appended to the url (using Get data from page URL).

For example if the page is hit with:


… the path will be the string “justiceleague”.

Presumably, this is the name of a Team in your database. You can then populate info on the page for that Team by

Do a search for…Team (constraint: Team’s Name = that_path):first item

(Remember that a Search always returns a list of objects, thus the :first item.)

If the Search returns empty, there is no team with that name and you should handle that condition — in my walkthru above, I put an error message on the page.

Hope this helps!

Best regards,

1 Like

Thanks so much @keith ,

How would I append the URL with the team name initially? ie; They fill in an input on the homepage with, for example, ‘Acme Company’ which then gets written to the DB. How then would I enable this to be appended to a URL ie; mysite.com/team/acme-company

Many thanks

@hikaru I’m not quite sure what you’re going on about. As you can see in the reply that I linked to, I did in fact build that. I had no need for it personally, but did it to help out another user who asked how to do that.

The reason I said “hypothetical” is that it was merely a question… “How might I do this?” I answered by showing – in great detail – how it would be done. If you follow the instructions in my response, you can recreate exactly what I did in my demonstration. :wink:

There’s screenshots and everything.

Again, what I’m explaining in this reply is a generally applicable technique. It shows how one can create a page that – instead of getting information on a thing by sending the page the unique ID of some object (“thing” in Bubble parlance) as the path, which would be the typical way – we can instead send an arbitrary value and then, via a Search, retrieve a thing based on this the arbitrary value that is found there.

The applications for this idea are many. But they all essentially boil down to: “I want to have a dynamic page that doesn’t take a cryptic uid as its path argument. Rather, I would like to use some ‘friendly’ name or human-readable path argument that stands in for that uid. How would I do this?”

The general technique boils down to the following:

  1. Create your page as you would any dynamic page. However, you would not (in general) give the page object a type. (Doing this complicates things.) As you design the page, you will not assume that the page object has a thing associated with it. You will instead grab the value of the page path yourself and take action based on that as described in 2 and 3 below.

  2. On page load, retrieve the path. If the path is empty, this is just like the case when the path is empty on a “typed” page (e.g, the “Page’s thing is empty”) and should be handled similarly – either display an alert, redirect the user, etc.)

  3. If the path is NOT empty, you will typically want to retrieve that value and stash it somewhere for ease of reference. It could go in a custom state located anywhere on the page. You can then have a group or groups on the page that you give types to. For the group(s) source, you Do a Search for… (the thing represented by the path argument).

  4. Now inside that group you can build whatever interface you want to and have the fields and such just inherit the values from the parent group – very similar to how (in the usual page-has-a-data-type case) things on the page will more of less automatically inherit their source from “Page’s thing”.

  5. Of course, you’ll probably want that “master group” not visible on page load. You would show it when your Search for the source thing has been successful and keep it hidden when not. (Conversely, the “error” version of the page – should you choose to have one – would be shown in the case of an empty path or a path that does not successfully retrieve a thing.

  6. All of the above should sound kind of familiar – because it’s basically like how you would build any sort of “search” type page, or how you would have a page (for example) of type User, but then have a group inside of it that shows some other type of thing (sourced from a search), OR retrieving a thing from a URL parameter that represents some object …

The only difference is that we are “automatically” executing a search on page load. And the search term is retrieved from the path rather than from an input, from a URL parameter, or some sort of constant. (“Path” is basically the same thing as any other URL parameter, it just doesn’t have a key. Consider that:


Is just a sexier way of writing:


as long as our page logic understands that what to do with this path argument.

  1. Some caveats: Obviously you need to think about the path argument in a URL-friendly way. So, let’s say that you allow folks to give their Team a name that is any valid string. So as an example: Batman, when setting up his Team, might name it “Justice League”.

Now, it’s not acceptable to build a URL like:

example.com/team/Justice League

That’s not a proper URL. You could URL encode that string, but then you have ugly replacements. (All the %20 garbage, etc. And Batman hates the look of URL encoded strings.)

A better idea is this: When a user creates or updates the Team’s Name, you also make a URL version and store that, too. (Perhaps on a field like Team’s URL Name or similar.) My suggestion for this would be to create a URL Name that is either:

Team’s Name:search and replace (replace whitespace characters with nothing):lowercase

Or perhaps:

Team’s Name:search and replace (replace whitespace characters with ‘-’):lowercase

So that the Team URL Name (built from “Justice League”) becomes:

justiceleague (in the former case) or justice-league (in the latter case).

I could go on and on about nifty variations on all this, but it’s actually quite easy when you start thinking of this in terms of what’s really going on – we are, at the end of the day, just building a search type of page with an automagic search that happens on page load, where the search term comes from the URL path.


Hi @marc2,

What you are doing is essentially what I would call “creating a profile page with a friendly URL”, right? (In your case, this is a “profile” page for a Team. It’s a “team profile” page, eh?) Why do we desire to do this?

Well, we desire to do this most often when such pages are publicly accessible and we want the URL to seem friendly. (If the page isn’t publicly accessible, it’s like “why the hell should anybody care what the URL looks like?” Just use the built in page-has-a-type / send uid of thing to page technique and save yourself a lot of hassle.)

And the reason we do that “make the URL friendly” stuff is so that the members of the team can then share outside of your app a nice-looking URL. Like, they could put it on a business card or something or share it on social media, etc.

SO, a couple of things:

  1. You need to display this info to the user so that they can share that URL. Somewhere you have a text element or whatnot that says:

Oh hai! The public version of your Team Profile is at:


(And of course, you just build that as some static text (the https://example.com/team/ part) followed by some dynamic text (Team’s URL Name or whatever you’re calling it – see my “caveats” I wrote in my reply to @hikaru for some pointers around that).

Now, if you want to link from that page from INSIDE your app, you can have a button or link or menu item or whatnot that does a workflow. That workflow is like this:

Workflow action (we have to use “Open an External Website”, NOT “Go to Page”, as we must construct the URL ourselves):

^^^^ My example above is generalized. The white text is where I just typed the starting stuff in the URL – for you this would be https://yourapp.com/team/

The dynamic part (shown in blue) is just an expression, right? For you, it would be whatever-expresssion-you-need-to-retrieve-the-teams-URL-name.

What we are doing is simply manually constructing the destination URL.

1 Like

Umm… OK.

If you build the page correctly, you won’t see it “flash”. As I noted, one fancy thing one might want to do is not show any page elements, until we’ve determined what we should be showing.

Sure, in a quick and dirty mock up of this idea, you wouldn’t take the time to do that. But for a nice profile page in your app, you’d want to.

But that’s a really easy thing to do. Everything on the page should be hidden on load. Then, whatever it is you want to show (for example, the “there’s no such team as justice-league” versus a profile for justice-league that exists) would be made shown depending on what we find in the URL path and whether a non-empty path resolves to an actual object.

It could be, @hikaru, that I do not understand what you mean by the page “appearing to flash”. I don’t see anything different in the storywall example or in my own tests between “go to page” and “open an external page” behavior.

The page clears. A new page appears. In both cases.

… What I think you’re referring to is this feature of your page:

^^^ when Faye here is clicked, we see the browser URL change (it changes first to Faye’s profile page with with her unique ID appended and then the Browser plug-in rewrites the URL we see displayed.

But there’s no actual navigation action that happens (the page is not reloaded, but the URL changes, so Get Data from URL’s result changes). In this way, data about the newly-selected user shows up in the page, without actually reloading/fetching a new page response from the server.

That’s a nifty technique. I’ve not explored the Browser plug-in. I’m assuming that’s a feature of Browser’s “Modify the URL” action? (Browser disrupts the normal navigation action?)

OK, thanks for confirming. My question is: why do you even bother with this:

You don’t ACTUALLY want to navigate. You’re just faking navigation by rewriting the URL in the browser/browser history. (Which doesn’t trigger a page reload.)

Shouldn’t you just call Modify URL in Browser:

But instead of what you’re doing, just send the URL as:

The second find & replace is like this:

In this way, the “original” URL, like:


transforms into:


(And so, you see, any arguments are preserved and we do not need to futz with differentiating between dev and live mode, etc. This is fairly robust, as long as the user cannot have a username the same as the page name, of course.

Edit: Additionally, you’ll note that doing it this way the workflow is reusable – we can change – and indeed don’t even need to know the name of this page and never need to update this text expression!)

And then, all you have to do is ensure that, after the URL is modified:

Ensure that the value of Get path from page URL gets updated. (It’s not clear to me that it would auto-update, though it may.)

If not, you’d just get path from page and shove that in a custom state (which is what your expressions around the page should be getting the user’s profile name from, rather than having a bunch of different “get path from page” expressions all over the place).


… and, BTW, I know you know this, but for other people who may be following along:

In your case, @hikaru, {new_user_expression} is Current Cell’s User, since the clickable shape is in that RG of Users. (BTW, if you found that you couldn’t retrieve “Current Cell’s User” from Shape A, what you’d do is make Shape A not clickable and use its parent group (which you just have labeled as “Group User” right now) as the click selector.)

1 Like

Thanks for the detailed response @keith but when I navigate to https://mysite.com/team/team-acme I just get a 404?

Having trouble understanding how you create the Team dynamic page? I can link to mysite.com/team but not to mysite.com/team/acme-company

Any ideas why?

@keith with this method, I am unable to connect 2 Data Types where I could use Data to send on a Workflow. This will not send across the correct information between pages?

I can use Go to page in a workflow, but then I get URL’s like the following mysite.com/team/team-acme-1673163173617816378163817??

Really stuck on how to fix this?

So team/acme-company (with this part of the URL being the profile page?)

How could I have this dynamically change though in the URL ie; team/acme-company instead of team/profile


Hi @marc2,

As in my example, you will not use Go to Page to navigate to a team page that uses this dynamic path argument technique. If you’ve set this up the way that I suggest, you will navigate a user there using a URL that you construct yourself, not one that Bubble will build for you. Perhaps I described that a bit out-of-order, but it’s the first thing I point out in my original reply to you. The section that reads:

We use ‘Open an external website’ as what that action really is is a way to construct destination URLs using any method we need (not just ones that are built into Bubble).

Thanks @keith But when I follow those steps I cannot seem to send Data correctly between the 2 pages?

ie; User enters a Team Name on homepage ie; Team Acme. This gets added to Data Type ‘Teams’
On the Team page user can then enter Team Members to Data Type ‘Members’ which is connected to the Data Type ‘Teams’.

This is where the issue arises. I cannot seem to connect the 2 Data Types following your method? With the Go to page method all is good, but then I get urls like team/team-acme-81398319381938391

Just to be clear, the reply I just posted addresses both of your questions (and thank you for being so specific about the issue you’re running into)! See that reply here: Easiest way to create a page/URL from Inputs value?

But also, here’s another explanation of what we are doing here:

Please note that the core of the technique that I’m describing is that the /team page you are creating does not have a datatype and we are are not “sending data” to the page in the default Bubble way. We are not sending the unique ID of a thing of type team.

We are instead sending a value of our own choosing – a text value that we append to the end of URL. By itself, this is meaningless to Bubble.

The destination page (/team) has logic on it that figures out what data it is supposed to be displayed, based on that arbitrary text value. The text value we are sending (the “team name”) is just a URL parameter – a special type of URL parameter known as the “path”. Unlike other URL parameters, it does not have a key associated with it.

But what we’re doing is analogous to a page you’d access like:


This might be a little easier to understand. “A-ha,” you would say, “Page /view-a-team takes a URL parameter called teamname that specifies the name of a team to fetch and display. And the showmembers URL parameter probably indicates whether the page will also list our the members of the team (if true) or not (if false).”

We are building a page like that. Just – in this case – we are passing some_team_name as the path parameter, rather than a key/value pair parameter.

In either case, the page in question must have logic on it that parses the URL and then delivers the information we’ve requested.

This topic was automatically closed after 70 days. New replies are no longer allowed.