Forum Academy Marketplace Showcase Pricing Features

Best practice for maintaining different states of the same thing for multi-user?

Hi everyone, I’d love some guidance from more experienced Bubblers on this.

In my app there are inline Notifications (basically info boxes) that are shown to users on different pages.

The user can close them or mark them as “Don’t show again”.

My question relates to how to save this information on a per user basis.

Right now I have the Notifications defined in the database, but because I need to store their state for each user I’m not sure of the best way.

Up until now, the way I’ve done it is when a user signs up, I run an API workflow that creates “My Notifications” entries for all possible system Notifications, which reference the original source Notification and have an additional field for the “Don’t show again” status.

Is there a better way? It feels like running all these workflows to set up a user (and many other things in my app that follow this pattern) is not only slow but could lead to some problems down the road.

Any insights are very appreciated.

Could you have a field on the user object to represent this choice? Or a field for notifications and Save data that’s notification specific to the user perhaps?

In my apps that use onboarding I usually have at least 1 field dedicated to track how far through a tour someone is. So if they go halfway thru. Leave the app. Come back tomorrow, the first half of the tour doesn’t fire but the second half will when the user enters that part of the app for the first time.

2 Likes

Hi there, @oli1… I may be missing something or oversimplifying things, but couldn’t you have a list field on the User data type that stores a list of the notifications that a user has marked as don’t show again? Then, when showing notifications, you can check a user’s list and only show notifications that aren’t in the list.

Anyway, just a thought.

Best…
Mike

2 Likes

I do what @mikeloc does. A list on the User, which contains an option set of “Things I want to mark on this user” - then I can easily do a condition on that user “if list does not contain XXX” …

That list represents “my ideal user lifecycle”…

3 Likes

Thanks, Mike!
I was thinking of something similar but hadn’t wrapped my head around it.

To try and unpack it, I’ll expand to include more of the settings that could exist, as I’m following the same approach for many elements (which is what led me to think there must be a better way).

Let’s assume the app contains the following system “things”:

  • 100 Notifications
  • 5 onboarding flows which include x onboarding steps in them
  • 3 courses that have modules>lessons>videos, each of which has a number of points the user gets for completing that video/lesson/module
  • and more

I’m not sure how the list that references all of these things would be set up.

To @lindsay_knowcode’s point about the option set, what would the structure of the “List on the user” be? And would I need one of these lists for each type of thing? (notification, onboarding, course etc) or could it all be rolled up into a single big list?

Really appreciate the help.

Hmm, I don’t think trying to combine all of that into one list would work, and even if it did, it probably wouldn’t be ideal from multiple perspectives.

I would probably track those things separately through fields on the User data type. It’s hard to say exactly what the fields for onboarding and courses would look like, but I still have lists on the brain here, so maybe lists of completed things that could be used for multiple purposes (e.g., understanding where a user left off, tallying the points associated with the things in the list, etc).

1 Like

Forgetting the complexities of the other use cases for now, I ended up following your initial idea and I have a list of “Notifications I’ve Closed” for the User, which I add a notification to when they click “Don’t show again”.

Wayyyy more elegant and simple than what I was doing before!
Thanks again, Mike. (And the others on the thread suggesting similar approaches).

1 Like