3 semanas atrás
- editado pela última vez
3 semanas atrás
Participante
Benefits of using new SERVICES object over a custom object
resolver
Hey there,
We have been developing a custom object to track our client's service inventory and just saw that @hubspot has added a new standard object called SERVICES to the object libary. (See below). Our development team is trying to decide if we should finish developing our custom object or scrap that custom object and customize the new SERVICES object instead.
Good question! The new service object definitely has some perks over a custom object. Here’s a quick breakdown.
Pros of using the new services object, Since it’s a standard object, it’ll naturally work better with HubSpot’s built-in tools like reporting, workflows, and lists.
HubSpot is likely to add more features and improvements to standard objects, so you won’t have to worry about rebuilding custom solutions later.
Less setup and maintenance using a standard object saves you time configuring and troubleshooting.
Cons of switching to the SERVICES object,
Standard objects might have less flexibility compared to custom objects. So, if you have very specific requirements, you may need to compromise.
If you already have data and workflows set up for your custom object, migrating everything could be a hassle.
If the services object covers your main use cases, I’d lean towards switching long-term, it’ll probably save you some headaches! Let me know what your dev team thinks!
Good question! The new service object definitely has some perks over a custom object. Here’s a quick breakdown.
Pros of using the new services object, Since it’s a standard object, it’ll naturally work better with HubSpot’s built-in tools like reporting, workflows, and lists.
HubSpot is likely to add more features and improvements to standard objects, so you won’t have to worry about rebuilding custom solutions later.
Less setup and maintenance using a standard object saves you time configuring and troubleshooting.
Cons of switching to the SERVICES object,
Standard objects might have less flexibility compared to custom objects. So, if you have very specific requirements, you may need to compromise.
If you already have data and workflows set up for your custom object, migrating everything could be a hassle.
If the services object covers your main use cases, I’d lean towards switching long-term, it’ll probably save you some headaches! Let me know what your dev team thinks!
I really appreciate your responce to my post. It was very helpful. My team is wondering if the new SERVICES standard object is considers a Beta solution and they are concerend about bugs. Any thoughts on this?