クリエイティブな才能を開花させよう

We use a large number of custom objects, and it's getting to the point where seeing the 'custom object' icon is getting a bit ugly for me. I would like the ability to provide a custom icon for these objects.  I would be ok with being able to just select from a template/color selector, if that would be easier for HubSpot to implement.  However, I think it would be much cooler to allow us to upload PNG/SVGs to our file manager and reference those in our Custom Object schema.    ...その他を表示

We have to define the objectTypes that a custom workflow action supports explicitly (or leave it blank for "any object"). Because custom objects have per-portal objectType ids -- we cannot have a workflow action that just targets custom objects.   Instead we have to open it to "any object", which leads to people accidentally trying to use the workflow on objects like a Contact.   We also don't get the objectType on which the workflow is running, which causes us to have to prompt users to manually select one so we know what objectType to make API calls against when the custom workflow action runs. ...その他を表示

We create properties in HS Portals to store data that we sync as part of our product. But we cannot mark them as read-only (despite being the ones that "control" the value).   As a workaround, we constantly sync the values more than necessary just to ensure that no one has changed the values in the HS side.   This also causes customer confusion when they expect two-way syncing (changing the property in HS and expect our product to reflect that change, in reality we just write over in the next sync).   You can restrict access via admin UI but not API.   This is generally useful for HubSpot apps that manage properties. ...その他を表示

There is no API access to property restrictions rules like "Date not in the past" or "Number must be positive". Portal admins can create these restrictions and our API calls will fail if we try to send invalid data.   We have to work around this because if we send invalid data as part of a bulk update, the whole update fails -- so we have to pull out the invalid data and retry.   Additionally we cannot do any kind of validations in our product on these properties when we are collecting the user-input. We've had customers use these restrictions and then failed to sync because of validation rules.   This is generally useful for HubSpot apps that write to user-defined properties. ...その他を表示

Zoom paid accounts now automatically summarize the calls through their AI summary tool. you have to toggle it on in settings. For me, that's the most useful thing Zoom does. to have that summary in HubSpot - automatically - means i don't need to summarize every call myself. Golddust. who votes for this feature?? tnks! Mike ...その他を表示

It will be better if we can get the status of a user through user API endpoint.   When I make a call to the GET Users API endpoint to get the details of a single user, I am getting the response with first name, last name, email, role details, team details and if he/she is a superadmin or not. Response json: { "firstName": "string", "lastName": "string", "primaryTeamId": "101", "roleIds": [ "string" ], "sendWelcomeEmail": true, "roleId": "100", "secondaryTeamIds": [ "102" ], "id": "123", "superAdmin": false, "email": "newUser@email.com" } But in this response, there is no key present to identity if this user is active or inactive in Hubspot. Also, there is no API that supports to activate/deactivate the user from the IDP. Also, I noticed that it is possible to deactivate the user only from the Hubspot side alone but this user will still be active in the IDP side which leads to consistency.   My suggestions: 1. It will be better if there is an API supported that allows the IDP to change the status of a user(active/inactive) because Hubspot allows to change the status of a user from Hubspot side alone. So this would make sense. 2. Also it will be better if the status of a user is sent in the GET user response as I explained above. Looking forward to the response from the Hubspot team regarding my suggestions. Thanks in advance. ...その他を表示

In our business case, we encounter a need to access more than 10,000 results in our search API calls. Presently, we generate reports based on the last modified date of deals, updating our database daily with changed deals. The challenge arises when the number of updated deals exceeds 10,000 on certain days, causing us to miss updates for more than 10,000 deals. We propose introducing an offset parameter in the API call, where the limit and after parameters currently work only up to 10,000 results. Below is an example of the API call we envision: URL: https://api.hubapi.com/crm/v3/objects/deals/search body: { "limit": 100, "after": 10000, "sorts": [""], "properties": [ "manual_delivery_ticket", "hs_pipeline" ], "filterGroups": [ { "filters": [] } ] } We believe that adding an offset feature to the API would provide a viable solution to this limitation. We understand the need for limitations but seek the ability to iterate through multiple calls to access all updated results effectively. ...その他を表示

Hi all,   I've contacted Hubspot Support regarding Server Side support and they told me there is no official support (there are some workarounds from 3rd party members). I said thank and if they could relay it to their engineers that Server Side tracking is essential for many companies as cookies are very blocked and many people use ad block. They told me to post my idea on this forum.   Any chance Hubspot is working on supporting Server Side tracking or would be willing to take it up on the roadmap?   Best, Kai ...その他を表示

One of the strategies to sync Hubspot and any database is using the property 'hs_lastmodifieddate'.   The idea is to use the search endpoint and return just the objects that has 'hs_lastmodifieddate' after then last sync. So the sync is fast and cheap.   The problem is that when user associates/dissociates any object, the property 'hs_lastmodifieddate' doesn't update, excecpt in cases where the property "number of associated X" exists. For instance, when a contact and deal are associated, the property "number of associated contacts" on deal is updated and, then, the 'hs_lastmodifieddate' updates (due to property change, not association).   The other solution to that is always read all records for syncing, to ensure all associations are updated, the problem with that endpoint is that when the number of properties is too long it raises 414 error (the search api does not requires properties as params in URI). ...その他を表示