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

who: theme customers, especially those with more than one child theme what: ease of use, ensure correct theme is used, limit theme to specific users value: more control, less guessing   Allow admin to set permission access to specific themes for users/teams and/or determine a global default theme. (ex: only child theme is accessible to marketers) (ex: child theme A is accessible to team 1, child theme B is accessible to team 2)   Most customers running their website with a theme from the marketplace use a child theme. Once the child theme is setup, the parent theme doesn't really need to be accessible from the theme choices.   Also, customers who have a current theme and are working to develop a new theme, may not want users to access the new theme until it is launched.   Ideally this would also eliminate the issue with duplicate system, blog, and email templates from appearing in the dropdown list (only those of the active theme should be in the list). ...その他を表示

A individual producer's ability to maintain data integrity appears questionable at best and is highlighted during the import process.    Here are a few of the issues I'm running into with HubSpot Imports & Data that I haven't had with other softwares.  1.  I can import a list of contacts and if some of them are assigned to another 'contact owner', I am not notified during the import process what contacts failed to import. 1A.  I am being told that in HubSpot this isn't actually counted as a failure, but rather on the contacts who were already assigned to another owner, the other fields updated, just not the contact owner.  So essentially, I could have just changed all the information for a contact that I don't even own.  Furthermore, the contact owner who just had the information on one of their contacts changed, has no idea. **If one item in the row fails, then the whole row should fail and be reviewed.  If data is owned by a contact owner for the purposes of selling directly to that individual, they should have control of the information or be informed when information is adjusted**   2.  There is no ability to check for conflicts before importing except manually comparing line by line to the system list of contacts. **Many softwares have the ability to run a test import before submitting the final import.  A conflict report is provided after the test is ran.**   3.  Contact owners are not notified when ownership changes. **ownership can change for many reasons - admin change, user change, toggles such as "auto assign to company owner" change - but the person who enters the contact is not notified.  They also aren't notified if the contact is already in the system.  It just dissappears.**     ...その他を表示

It would be great if there could be more detailled permission settings for access to lists. For some users, I only want to give them a read access to all or even better only to certain lists. As of now it is only possible to completely close or grant access. So everyone who is able to see lists, is also able to delete them or change filter options etc. ...その他を表示

At the moment it looks like SCIM provisioning is only supported with Okta. https://knowledge.hubspot.com/account/provision-hubspot-users-with-scim-through-okta   It would be good to have either an integration for SCIM user provisioning with OneLogin or a generic SCIM bridge that we can use for setting up SCIM provisioning and security permission/group provisioning from OneLogin. ...その他を表示

It would be beneficial if multiple departments can collaborate on a single support ticket. This way multiple tickets do not need to be created for a single case issue.    Idea: If a single support ticket could host multiple pipelines and statuses and when one team creates a note, logs a call, sends an email, etc then everyone listed as a collaborator (or owner) of that ticket can view the activity. If the single ticket can host multiple pipelines and statuses then each department can follow their specific process and retain metrics for their worked tickets.    Essentially, having multiple owner lines so each department that is collaborating can own the ticket.  No matter what activity is done on the ticket all owners (or collaborators) have visibilty. So when one department resolves their portion of the case then the next department knows it's their turn.  This will help support agents know which department they are still waiting on for action in order for them to resolve the case.  Being able to see who is viewing that ticket live so multiple people aren't doing the same thing at the same time. ...その他を表示

We need to see who is using the email add-on, as they may be unaware their private emails are being stored on a company CRM system, which would be a huge breach of privacy. As SuperAdmin I want to be able to inform these people to be careful, as they may have downloaded the Add-On with no prior engagement with an Admin or Super Admin. ...その他を表示

Currently I'm running into the issue that i cannot delete an old property, when they are still being used in a view. As a superadmin, I'd like to have the possibility to overrule this and delete this anyway.   Because I'm not able to edit the view that is managed by another user (of which I also cannot see which user) and delete this property from their view.   Currently this leads to clutter in our database. ...その他を表示

I've just had a chat with one of the team and he directed me here to make a suggestion for a feature.  I have a sales team who are very lazy and don't tend to look at the contact notes before calling the client as they have a script to read off.   I sometimes get clients ask to be rung at a certain time or day which I write in the notes - however this gets missed and they're called as soon as they're added which makes us look unprofessional. I would like to add a column to leave a quick note, i.e. "Call on Tuesday 5pm" - so it's right there next to the phone number.   Also the ability for the superadmin to edit the main contact table view for the whole team so that I don't have to manually edit each table view.    Many thanks 🙂   ...その他を表示

I would be mind-blown if someone hasn't already created a post about this, so if someone has, feel free to let me know.  Right now, as far as I can tell, the fairly basic action of creating an association label is a feature that is only exposed to Super Admins. That is a massive security concern. In order for our users to use this feature, we now have to give them complete and unfettered access to our Hubspot account? We (as I'd imagine most security-concious organizations do) heavily restrict access to the SuperAdmin role due to the dangerous actions that can be performed with that role and don't even allow our Hubspot Administrator to have SuperAdmin access by-default (She has nearly every other permission besides user management, bulk data export access, and a few other potentially hazardous actions). Historically Hubspot's granular permissions have been really solid and allow for least-privilege principles to be applied, but this is a big outlier that (IMHO) needs to be fixed ASAP.  Please expose association label creation as a configurable permission for other roles besides the SuperAdmin role.  ...その他を表示