Contacts

Currently you can delete unused custom fields one at a time. However, there is a select option, but when you select multiple custom fields to delete, the delete function disappears and the only option is to move them into another folder (Contact Info, General Info or Additional Info) Surveys can get extremely cluttered when there are a lot of unnecessary custom fields (use case: loading a snapshot that has a lot of custom fields) It is time consuming to have to delete unused custom fields one at a time instead of a Bulk Delete.

When we search for contacts (via Conversation, Contacts, whatever) it ALWAYS seems to take 1-3 attempts of typing in the name to get the system to pull up their account. It's just frustrating after doing this 100's of times over the past few months. Can we look into fixing the search index?

When you delete a contact and then restore it, HighLevel silently creates a new record instead of re-using the original. That creates duplicate contacts in the account with same email address. All users whether or not they had access to the contact, can see the contact's information in the 'Restore' tab which creates GDPR issues. Any user, regardless of whether they had access to the contact or not, can view and restore deleted contacts. This behavior: Bypasses the built-in email uniqueness check Lets restricted users see contacts they don’t “own” Exposes personal data across users, which conflicts with GDPR principles Steps to Reproduce: Create a contact with a given email (e.g. test@test.com ). Delete that contact. Go to “Deleted Contacts” and click “Restore.” Observe that a second contact record appears with the same email. Log in as a user with limited visibility and verify they can see contacts in the 'Restore' tab. Expected Behavior: Restoring a contact should re-activate the original record (no duplicate). Users should only see contacts for which they have permission to view, whether the contacts are deleted or not. Actual Behavior: Each restore action creates a brand-new contact record with the same email. All users, even those with restricted access, can view contacts in the 'Restore' tab Impact: Data Integrity: Duplicate records for the same email cause confusion and campaign errors. Privacy Compliance: Exposes personal data to unauthorized users, risking GDPR violations. Please address this as a high priority bug. Restoring contacts should not create duplicates, and visibility rules must apply consistently to deleted/restored records.

This is really problematic. Users who are generally the managers/employees in the ghl sub-account SHOULD NOT become contacts in the system. Having to make the user(manager/employee) a contact(lead/customer) in the system to track activity is really concerning, and I can't understand why this is not a huge issue for everybody. Because this scenario unfolds with sample of following users user(manager 1) user(manager 2) user(employee 1) user(employee 2) user(employee 3) A contact passes through an automation and say the automation notifies user(manager 1) about a contacts behaviour/action using the internal email notification action. user(manager 1) now becomes a contact(lead/customer) in the system and gets the notification email. Now later on when user(manager 2) sends an email to user(manager 1) all the users(employees) can now read this email !! (manager 2) could be emailing (manager 1) about discussing the possibility of raising a disciplinary issue with one of the employees and now everyone sees this email!!! Or (manager 1) sends a financial report to (manager 2) everybody gets to read it! (I appreciate you can make users at the employee level data visibility scope only assigned data but that silos everybody) Is there anyway you can put in the necessary tracking of user actions without having to make the user a contact(customer/lead)? This is causing a real headache - if it cant be resolved we might just have to go the 'view only assigned data' option for all users.

When creating/updating an opportunity in a workflow, it's not currently possible to update a numerical or monetary field using a bracketed value. You have to type a number. This is actually a workaround for not being able to update Opportunity fields via a LeadConnector zap action (have to update contact fields via Zap, then update the opportunity in a workflow). But cannot update the opportunity properly in the workflow without being able to dynamically populate numbers like {{contact.30_margin}} (see image attached).

Hi Team, I am currently facing an issue with creating a contact using ClickUp email or list , which I was previously able to do. Issue: GHL restricts email ID lengths to a maximum of 83 characters, whereas my new ClickUp link is 84 characters long. As a result, I am unable to proceed. Can you assist me in resolving this issue? Note: Earlier, I was able to create a contact using a ClickUp email.

At least when importing I see here that Monetary is spelled incorrectly

URGENT!! No way to make any bulk actions based on calendar. I cannot even add tags or process any workflows for existing contacts based on which calendar they used!!!! URGENTTTT

Africa/Dakar, Africa/Accra, Asia/Katmandu, Africa/Addis_Ababa, Africa/Mbabane, Asia/Manila are just a few of the timezones that were in contact accounts within our system from spam bot traffic. The timezones are added to the customer account automatically should adhere to strictly the timezones available in the search list or provide a text search option for the Timezone search so I can delete the harmful bots en masse

Currently, GoHighLevel displays a warning for emails with no subject in the email campaign checklist and template settings. However, this validation is not applied to emails sent individually to contacts, which allows messages to be sent without a subject. This inconsistency may compromise the professionalism of communications and potentially impact email deliverability. Proposed Enhancement: Universal Validation: Implement the same subject validation for individual email sends as is in place for campaign checklists and template settings. Handling Emails Without a Subject: Option 1: Prevent the email from being sent if the subject field is empty. Option 2: Display a clear alert (e.g., "Are you sure you want to send an email without a subject?") before proceeding with the send action. Expected Benefits: Ensures consistent behavior across all sending scenarios. Enhances the professionalism of outgoing emails. Helps prevent potential deliverability issues related to missing subject lines.