Contacts

Feature Gap in Appointment Payment Tab — No Payment Link Option & Risk of Duplicate Payment Records
SUBJECT: Feature Gap in Appointment Payment Tab — No Payment Link Option & Risk of Duplicate Payment Records Dear Support Team, I would like to flag an important workflow limitation and a potential data integrity issue related to payment collection on manually booked appointments via the mobile app and the CRM platform. ## Issue Summary When a client is manually booked for a service appointment and no payment is collected at the time of booking, there is currently no way to send the client a payment link (for either a partial deposit or a full payment) directly from the Appointment's Payment tab. This creates a significant workflow gap and introduces the risk of duplicate payment records. ## Detailed Explanation ### 1. No Payment Link Option in the Appointment Payment Tab The Appointment's Payment tab currently only supports two methods of payment collection: Charging a card that is already on file for the contact. Manually entering card details at the point of collection. There is no option to generate and send a payment link to the client directly from the appointment — whether for a partial deposit or a full payment. This is a critical gap, especially in scenarios where the client is not physically present at the time of booking and the business needs to collect a remote payment after the fact. ### 2. Risk of Duplicate Payment Records Because the Appointment Payment tab does not support payment links, the only workaround available to collect a remote payment is to create a separate manual invoice and send it to the client as a payment link via Payments > Invoices. However, this introduces a serious reconciliation problem: A manual invoice payment is recorded as an invoice transaction , independent of the appointment. It is not automatically linked to the appointment's order or payment record. If a staff member subsequently uses the Appointment Payment tab to record or collect the same payment (unaware that the invoice was already paid), the system will record two separate transactions for the same payment — resulting in duplicate payment records for the same client and the same appointment. This is not immediately obvious to users, as there is no warning or cross-reference between the invoice payment and the appointment's payment section, making it easy to accidentally double-record a payment. ## Impact Inaccurate payment records and financial reporting. Confusion for staff managing both the Invoices and Appointments areas. Risk of overcharging clients or recording incorrect revenue figures. No clear audit trail linking an invoice payment back to its associated appointment. ## Suggested Improvements Add a "Send Payment Link" option to the Appointment Payment tab — allowing users to generate and send a payment link for a partial deposit or full payment directly from the appointment, without needing to create a separate manual invoice. Link manual invoices to appointments — if an invoice is created in relation to an appointment, there should be a way to associate the two records so that when the invoice is paid, it is reflected in the appointment's payment history, preventing double recording. Duplicate payment safeguard — introduce a warning or flag when a payment is about to be recorded against an appointment that already has an associated paid invoice for the same amount. I hope this feedback helps improve the platform's payment workflow. Please let me know if any further clarification or screenshots are needed.
0
·
Bug
Critical iOS Issue: Contact Updates Failing on macOS and iPhone
Hello GoHighLevel Support Team, I would like to report a recurring and critical issue that affects contact updates specifically on iOS devices (macOS and iPhone). A large number of my clients are experiencing the following problems when working on iOS: Contacts cannot be updated (update fails without a clear reason) After marking messages as read, they reappear as unread The contact update window sometimes does not open at all When clicking Save, the system returns a “Failed” message even though no required fields were missed I am attaching screenshots and screen recordings that clearly demonstrate these issues. What makes this situation particularly concerning is that: The issue appears consistently on iOS devices The same actions work perfectly fine on Android and Windows Most of my clients are iOS users, and many of them are facing this problem daily Because of this, the experience is becoming increasingly frustrating for them, and unfortunately, it is starting to affect my business. If this issue is not resolved soon, I risk losing clients due to usability problems that are outside of my control. I kindly ask you to prioritize investigating and resolving this iOS-related bug as soon as possible. This is a critical functionality, and its instability is having a direct negative impact on user satisfaction and retention. Thank you in advance for your support. I am available to provide any additional details if needed. Best regards, Diana Panaghiu Sistematic CRM GoHighLevel Partner
0
·
Bug
Allow selective logging with Bcc email only
There should be a way, if you disable two-way sync, to just use a BCC email that will log the email you send to the proper contact based on their email. Why it matters: Logging into GHL to send every email is a barrier to logging conversations with contacts, but logging all emails to contacts is also problematic because it means other admins and some users can read your emails, some of which may contain sensitive data . I am the owner of my company but also the primary business development person. All my employees are contacts, and if I email them about something sensitive, I don't want it showing up in High Level. A potential solution: If 2-way email sync is disabled, allow for a unique (to the GHL user) BCC email, which will log the email to the contact in GHL. It would be great if this also allowed for a contact to be created (even though it will likely lack first and last name and other data if they are not already a contact. Benefits: This helps overcome nervousness about "everything" being seen in GHL, when all we need is business/sales related conversations, and also creates an easier way for people to log conversations on the go without needing to log in. I loved the inbox/conversations, and that I could reply from within it, until I realized it was logging ALL my emails where others could see them. Given the fac t that many business owners wear multiple hats (including HR) this is a bit of a liability. I hope this solution can be implemented quickly!
0
·
Bug
User becomes a contact in the system when sending internal email notification to user in automation!!!
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.
3
·
Bug
Load More