When a user clicks one of their “Notifications”, I send them somewhere on my site. I want to include that somewhere in the database.
As you can see below, it seems it’s not possible to dynamically specify a page using the internal “Go to page…” action.
(And maybe that’s okay because I would need 3 fields in the notification data type for destination, data to send, and send more parameters, which feels bloated.)
So I can do an external link instead, which means I’ll have the page, data, and parameters all in 1 field as a link.
I’m just wondering if this will come back to bite me, for example, will I lose all analytics data on how users move through my site? Or are there other downsides to using external links for navigation?
As a consideration, if you’re not doing so already, I’d recommend incorporating the website home URL feature into the URLs you create/specify. That way, your URLs will reflect consistently between your test and live versions and if you update the URL of the application.
For notifications, what I’ve often done is defined a “type”. Then, within the workflow, I had a series of only when conditions that would either start navigation to another page (with specific parameters) or an on-page action (agnostic of the current page) using a popup.
Otherwise, I don’t feel that there are any immediate downsides. Just a bit more to maintain when you make updates to page names.
Thanks @dan1 , yes, that’s how cobubble designed mine, but it means there are over 20 actions (with conditions) in my workflow, and no doubt many more than that over time as the app grows, which is incredibly inefficient.
I’d rather have just 2 actions that never need changing (1 for navigation to another page and 1 for on-page). It will also make the notification creation process much simpler because this side of things never needs updating.
I’m just wondering if there will be unforeseen downsides.
Expanding on the earlier point, for the notification, in addition to the actual content of the notification, you could add a few additional fields for constructing a URL.
Right, thanks, but I might as well put all of this into 1 field rather than separate fields, right? I.e. I might as well just build that link when I create the notification.
Correct, easy enough to have it in one assembled link that is saved in the notification. A reason I like to have it separated out is if any of the fields are conditionally updated, I can incorporate that versus having something static or if I want to reference a specific aspect more easily.
Conscious this was some time ago, but curious how you got on here?
I am considering also storing “URL parameters” in the database, as seems it would save a lot of “only if” workflows from needing to be set up.
Wondering if this is still okay practice, or if there’s another way to allow for dynamic navigation in bubble from contents stored in the database? I’m surprised that dynamic internal navigation isn’t a common need, unless everyone is just using the “navigate to external website URL” workflow.
