Morning - I’m building my most complex Bubble app in terms of the database and I’m having trouble structuring it. The current issue is that I’m not able to save information in the right place, this is indicating to my that my database structure is not set up correctly so I’m looking for help on
- How to set it up properly
- how to structure the work flow to save the data
- or perhaps, both!
Here’s the plain language explanation.
The app is called Sales Huddle. A Sales Huddle is a 1 hour zoom call where sales people come together to help each other with their current sales challenges. I’ve been running and managing this manually for 2020, it’s growing and I need to build an application. I’ve competent with bubble, I’ve built a paying app before, but I’m having trouble with this.
User types
-
Members - Each member has a profile with the details of their sales career. Members are signed up for Sales Huddles. Part of members profile has a log of all the sales huddles that they’re a profile of.
-
Sales Huddles - Each sales huddle is a unique instance. It’s comprised of members. Each member has to submit a ‘work statement’ before the sales huddle, which is what they want help with. Here is the data architecture for each Huddle
- Checkin + work statement. Members submit their work statements by ‘checking in’ before the sales huddle. Think like a boarding pass for the an airplane.
Here’s the current, I cannot get the work statement to save.
Here’s the how the work flow is set up
I’ve opened up the app for viewing. Here’s the specific page for the checkin:
I think the workflow is correct, I think the database is set up wrong because the “work” field in the Sales huddle is not saving. The “work statement” field is empty within the Sales Huddle that I’m trying to save for.
Part of the problem is that I don’t know what the problem is.
I’m comfortable with dealing with database lists that are a 1 to many relationship, this seems like a many-to-many relationship, and I’m not sure how to handle this.
Any thoughts?
Hi @topherwilliams,
This is remarkably similar to an application that I built but never launched, for a different vertical. One thing I note is that you have a sales huddle with several members but you seem to be trying to save each member’s work statement to the huddle as a whole. So are you expecting to end up with a list of work statements in a sales huddle? If so then the field should be a list if it isn’t already and you should be adding to that list from the input: work statement’s value.
If I’m correct in my assessment then I believe you’ll encounter another challenge in that you will have to ensure that you save the work statements in the same order as the members and when retrieving a work statement for a specific member, you will need to work out the member’s index and then retrieve the work statement with the same index, which is possible but perhaps not the easiest thing to do in Bubble.
In my app, I structured things differently. Mapped to your domain concepts, my structure would look something like the following:
- Work Statement: owner(User); title; description etc
- Sales Huddle: name; type; num of members etc
- Huddle Member: huddle (Sales Huddle); member (User); statement (Work Statement)
So in my workflows, users would create statements and when I create a Huddle, I would create members for it in turn, in the Huddle Member data type and register the member’s work statement as checked in for the week.
I don’t know enough about how your huddles are created to know if the above will work for you but I hope you find it helpful in some way.
Update: I wasn’t able to check your app before but now that I have, I can’t see where you are assigning the created work statement to the huddle. When the page loads and you create a work statement, it seems to me that you need to assign it to a huddle .
I had a (very) quick look and if I understand well you create a huddle/statement, then you DONT associate it with the user.
Then you try to modify the last statement of the user.
Sa you just have to add your new huddle to your current user immediately after creating it.
I may have missed something, and my answer is about workflows, not data structure…
EDIT: On the second look I understand from your post that you wanted to edit your sales huddle (adding the statement to it), but you “change a thing” action is actually changing a work statement, not a huddle.
You’d need to change the huddle, and the field would be “work” with the expression “add - result of step 1”
Yes! Awesome. Thank you for chiming in. This is exactly what I’m trying to do. I can see how making this a list is the right solution.
Around your observation here:
“If I’m correct in my assessment then I believe you’ll encounter another challenge in that you will have to ensure that you save the work statements in the same order as the members and when retrieving a work statement for a specific member, you will need to work out the member’s index and then retrieve the work statement with the same index, which is possible but perhaps not the easiest thing to do in Bubble.”
Yes, I agree that this is an issue, as I need to be able to easily search for and return a user’s work statement from a Sales Huddle.
So in my workflows, users would create statements and when I create a Huddle, I would create members for it in turn, in the Huddle Member data type and register the member’s work statement as checked in for the week.
Mine seems a little different, I’m not sure if it can apply. Here is mine:
- I create a sales huddle and invite members
- they “checkin” and submit their work statements.
- Those work statements are added to the Sales Huddle
I’m looking at this flow:
- Work Statement: owner(User); title; description etc
- Sales Huddle: name; type; num of members etc
- Huddle Member: huddle (Sales Huddle); member (User); statement (Work Statement)
It seems like you have an added type, Huddle Member, which is separate from a user/member. Is this correct? If yes, how is this different that a user/member?
I think this might be the missing bit as the Huddle Member is a user, and it connects both the Sales Huddle and the Work Statements together, both of which there can be many of it. Is that right?
1 Like
@louisadekoya and @philippe1 thank you for your help.
I realized it would be useful for me to share what I want to happen in plain language, as the current structure of the app does not display this. I think this will provide more useful.
I made this database map which (I believe) will work.
Here’s the process in plain language
- I/admin create Sales Huddle with different members in them in each week.
- Each Sales huddle has different members. (Row 9)
- When a member is selected, they are emailed a link to ‘checkin’ to the Sales Huddle and submit their work statement for that specific Sales Huddle. (Row 1)
- There work statement indicate which Sales Huddle it is for (Row 1, Column C) and then there work statement is also added to the Sales Huddle (Row 9, Column C) too.
- Each Sales Huddle runs at a specific time/date. At the time of the Sales huddle, I share a link with all of the members that show them the work statements submitted by the other members of the group for that Sales Huddle.
- When a member is on your their own profile, they can see a ‘work log’ of all of the past sales huddles they were in AND their work statements.
Do you agree that this database map will work?
If yes, my next challenge will be a) structuring it in bubble and b) making the workflows
If not, what needs to shift?
2 Likes
Yes, but I’m not sure what you mean by user/member. Basically, rather than having a list of members in the huddle table itself and a corresponding list of work statements, I would have huddle-member as it’s own data type and point each record here to its own work statement. If you’re worried about performance, you can still have a two - way link whereby you also have the huddle-members in the huddle data type.
The key difference in my approach is that having huddle-member as its own type makes it easier to record and retrieve work statements for a member.
I think I understand. You are more advanced than me.
Is the right structure that you outlined?
This would be adding the huddle-member to the Huddle data type to allow for two-way querieis. I believe huddle-member would need to be a list. Yes?
Yes, this is probably how I would do it. Of course, like all things with Bubble, there are bound to be other ways.
Just one point, I see that in your first table, John has two whirr statements (assuming the two Johns are the same user) but I take it only one of those statements will be used in a particular huddle m, right? If so then yes, like I said, the structure you have there is likely how I would go about it.
Thank you @louisadekoya . I think I know how to build this, I’m working on structuring the data types now, and then will work with workflows and such and see if I can get it going.
I’ll add to thread if I have any implementation questions.
I’m also looking to add Comments to work statements eventually, so my guess is that Comments will be a field within work statement, and then another table.
1 Like
@louisadekoya. Success! I want to share the specifics of how I implemented this, both to remind myself how I did, show you in case I missed anything AND share with others that might have a similar problem so they can follow the thread.
Here is how I set up the data types.
Sales Huddle
Work Statement
Huddle Member
Some workflows.
-
I create a Sales Huddle as an admin
-
When I add a member they get added to the member list. This is important for emailing them, but not tracking work statements.
-
And a new huddle-member is created that’s assigned that member AND the Sales Huddle they are placed in.
-
For the checkin, the user adds a work statement to a ‘huddle-member’ where they are active. And a user can only be in one active huddle-member at a time.
-
when the user submits the work statement. They create a new work statement
-
Then they add that work statement, so the work statement field in the active huddle-member that they are a part of and set the active status to no!
This last part took me a while to figure out.
Great that you’ve got it working. In your sales_huddle table though, I expected Members to be a list of huddle_member records, not a list of users.
Got it. Why is that? What am I able to do with that?
Right now, it’s a list of members so I can email them to checkin only, not as a reference of any kind.
For one thing, It’s for what is known in (relational) database design as data integrity. You shouldn’t be able to delete a huddle member record while the member it relates to stays linked to the huddle, for example. Also, for performance reasons, we said to have a two way link. If you wanted to display work statements for a huddle, given the way you have it set up currently, Bubble would have to search through potentially hundreds of huddle member records for those with the given huddle Id, because you don’t have a list of huddle members on the huddle itself. If you did, you could directly access their details. The expression … this huddle’s Members’ huddle_members’ work statements is more efficient than Do a search for huddle_members where huddle is this huddle.
@louisadekoya Would it also make sense then to have a ‘huddle-members’ be a variable in the User? It would be type: huddle-member and a list.
This way I can search by:
Current User’s
Huddle Member’
Sales Huddle’s
whatever details I want
Yes I think so - for the same reason.
I love it, thank you for your help, and also my brain is starting to explode with database complexities and learnings!
3 Likes
