I wanted to get some opinions on which direction to go based on a custom project scenario we have. First, a little background...
Phase 1 - Created a dashboard webpage that is set to "private - registration required" and displays data from a custom object based on the user that's logged in. This is working correctly but hasn't been taken live yet. Currently creating the project in a sandbox.
Phase 2 - This is the part where we want to get the strategry correct.
Client wants to create a "master" resource list and be able to assign any of those resources to a particular user. The assigned resources would then be displayed on the user's dashboard from phase 1. They also want to be able to assign/display "volunteer" contacts on the dashboard. Basically, we would be giving a designated group of users the ability to assign the resources/volunteers to a particular user. We would need a page where they could select the user then assign the resources and volunteers from the available lists. And then obviously, save the selected assignments for that user so they can be displayed.
1. How should we handle the master resource list - HubDB or a custom object?
2. Best option for saving the user's assignments for resources and volunteers?
HubDB seems like a logically choice especially for the master resource list. Only one or two people will be controlling that master list and could easily add/edit directly in the HubDB table. The one con is that it will limit us to utilizing the data just in the CMS.
The part I am not confident about is the best option for saving all of the user's assignments that were selected. Would we have to use the API to save the selections to the HubDB table?
Would custom objects be a better approach? Or is there another option that might work better?
I have been through your requirements and based on it I would like to share some of my suggestions-
1. Master Resource List: Since the master resource list will be controlled by only one or two people and doesn't require any complex relationships or integrations, using HubDB seems like a good option. It will allow for easy adding/editing of resources and volunteers, and can be accessed directly from the CMS.
2. Saving User's Assignments: To save the user's assignments for resources and volunteers, a custom object could be a good option. It would allow for more flexibility and could be accessed via the Salesforce API, which would make it easier to integrate with other systems if necessary. Each record in the custom object could represent an assignment for a particular user, and could include fields for the user ID, the assigned resource/volunteer, and any other relevant information.
Apartfrom that, you could also use a related list on the User object to store the assignments. This would allow for easy access to the assignments for a given user, and could be accessed via the API. However, this approach may become unwieldy if there are a large number of assignments.
The choice between using a custom object or a related list would depend on the specific requirements of the project and the complexity of the data relationships involved. But if the requirements are relatively simple, a custom object could be the best option.
In terms of saving the selections to HubDB, it is possible to use the HubDB API to update records in the table. However, depending on the complexity of the data and the relationships involved, using a custom object may be a better option.
Is it possible to update a Custom Object from a webpage?
My thought process...
Use HubDB to store the Resource Master list and a custom object for the member resource selections.
Create a page that allows the various selections to be made. It would have a user (member) search/selection field, a dropdown or a checkbox list of resources from the HubDB table that could possibly be filtered first by category, and a volunteer search/selection field. Submission of the various selections would then save the data to the custom object so that they could be displayed on that particular member's dashboard.
Does this approach makes sense? Obviously being able to build/execute it is the hard part. lol.
Create a custom object for the resource list then create another custom object to store the member resource assignments and associate it with the contacts object and the new resource custom object. I think this would eliminate the need to have a webpage to make the selections.
I will work through this in the sandbox and see how it goes. I will post updates once I have some.
thank you for speaking your mind out loud and let us see into your thought process as you figure out this challenge. Really appreciate it.
One thing I still don't quite understand however is the reason why you would need two custom objects. Maybe I'm missing something here, and you can get into more detail, maybe even with an example. The reason I'm asking is that in most cases, it's easier to work with less complexity. Especially if others need to work with this setup as well.
Making these changes you're mentioning possible on a webpage might be very hard to configure. We're using in some of our projects HubSpot's Serverless functions to access and change stuff within the CRM. But I would challenge that this is actually something you need. I, of course, can't speak for the entire use case, but I think it makes only sense if others need to make these associations between contacts and custom objects without being logged into HubSpot.
However, then that creates another problem. Accessing Contact Object Data is only permitted for logged-in users. See here for more information about that
Again, thanks for the response and your thoughts. I really appreciate it. This is one of the main reasons I wanted to post my scenarios and thoughts here. This is one of the most complex projects we've taken on and there are users/developers in this community that have significant more experience and knowledge.
I want to make sure we get this set up right so we don't run into issues later. I am all about not adding in complexity if I don't need to.
Let me see if I can explain the use case a little better and the reasoning behind 2 custom objects. I would be ok if I could make it work in one. As I mentioned in my original post, members have a dashboard that displays info pertaining to them.
Let's say there are 25 resources (name, desc, link) available to be assigned to a particular member and displayed on their dashboard. The client wants to assign resources 2, 7, 16, and 21 to member John Doe to be displayed on his dashboard. I need a place to save those selections.
Custom Object A - contains the list of 25 resources and the necessary fields.
Custom Object B (associated w/custom object A and Contacts) - contains the resource selections for member John Doe (4 entries). The dashboard page would read this object to know which resources to list for John.
I didn't see a way to make that work in one custom object. Also, this would eliminate the need to have a webpage to make the selections. New entries would be made within the custom object B. Obviously, I am open to a different approach if there is a better and more efficient way to handle this.
it sounds like you have it all sorted. Even if this is one of the more complex projects you've undertaken, you will do just fine, I'm sure of it.
One thing I'd like to mention if you like to test everything first. I can recommend getting a feel for it in a separate portal. If you have access to custom objects, that mean you have also access to the sandbox feature in HubSpot.
Maybe you're testing there already, but in case this is news to you, here is some more info:
thank you for reaching out to the community about your project. I always find it very interesting how other partners and customers think about their business processes within HubSpot.
I can definitely see and understand the thoughts behind HubDB vs. Custom Object. The main difference between the two that is important to you (from what i gathered at least) is the ability to connect records from CRM to the records from your the scenario. Especially if you're trying to get these records on a webpage dynamically, I personally would go with Custom Object.
To gain a logical connection between HubDB and CRM you would need to hack something together and probably create a column with all the IDs from the records that you want to connect from the CRM.
BTW: I think your use case could really benefit from the GraphQL beta. If you haven't checked it out already, here is some more info on that.
Regarding the volunteer use case I'm not entirely sure, what you/your client have planed here. I see a lot of customization effort here, if you want to make it possible for logged in users to create these associations. Without understanding everything down to the last detail, I could imagine association labels would make a ton of sense to at least differentiate the relationships between Custom Object and volunteer/regular user.
Hope I was able to help a little bit out, but please feel free to give more background info and keep the convo going.
Thanks for the response and suggestions. I plan to explore the Custom Object more today as a possible option for phase 2. I need to figure out what that might look like as far as the fields and processes needed.
I was not aware of the GraphQL beta so I will for sure take a look at it. As far as the volunteers, they would either be identified with a custom contact property or maybe create a volunteer list that could be referenced.