Custom Objects

Formula Fields are very useful at extending capabilities and allowing users to quickly create automatic calculations rather than manually entering results. A formula field is a custom field that automatically calculates values based on a formula expression. Formula fields are read-only, meaning users can't directly edit the value. Instead, the value is calculated based on the formula and the values in the source fields. This is not a new concept, since most CRM systems such as Salesforce, Zoho, Hubspot, freshworks, vtiger, salesloft, MS Dynamics, and Sugar all have the ability to create formula fields. If you are familiar with Excel, than you know how handy formula fields are as they allow us to create simple or even more complex formulas based on data from a record and from its related records if needed. Some examples of use cases that come to mind are: Dynamic Payment Calculations for Appointments or Services For example, if each appointment hour costs $150 Formula: ( {{appointment.only_end_time}} - {{appointment.only_start_time}} ) * 150 Lead scoring based on Engagement and Attribution Formula: IF( {{contact.attributionSource.utmSource}} = "google", 10, 5 ) + ( {{ contact.email _open_count}} * 2 ) Visualize Lead Temperature (using IMAGE and CASE) Formula: CASE( {{contact.rating}}, "Hot", IMAGE("/img/samples/light_Red_fire.gif", "Hot"), "Warm", IMAGE("/img/samples/light_Yellow.gif", "Warm"), "Cold", IMAGE("/img/samples/light_Blue_snowflake.gif", "Cold"), IMAGE("/img/samples/light_grey.gif", "No Rating")) Add 30 Days to an Enrollment Date Formula: ( {{contact.enrollment_date}} + 30 ) The ideal situation would be whenever your are creating a custom field and you choose the Formula Field Type, it would allow you to open a formula editor where you could construct the formula and insert other fields, operators, and functions. Here are some Operators that should be included: Math Operators (+, - , *, /, ^ ) Logic Operators ( =, <, >, <=, >=) Logic Functions ( AND, OR, IF, CASE, ISBLANK, ISNEW, NOT, IS) TEXT Functions ( FIND, CONTAINS, HYPERLINK, IMAGE, INCLUDES)

The Problem Currently, GoHighLevel Custom Objects lack the flexibility to visualize and manage records in different ways. Different industries and use cases require different ways of viewing the same data. A single table-style interface is not sufficient for managing projects, applications, inventory, bookings, properties, recruitment pipelines, and other operational workflows. Platforms like Airtable, ClickUp, Monday.com , and Notion have demonstrated how powerful customizable record views can be. Proposed Solution Allow users to create multiple customizable views for every Custom Object, all powered by the same underlying records. Requested Views: Grid/Table View – Spreadsheet-style interface with editable cells, customizable columns, sorting, filtering, and grouping. Kanban View – Drag-and-drop cards organized by status, pipeline stage, or any select-type custom field. List View – Clean, compact record lists with expandable details, grouping, and quick actions. Gantt View – Visualize records on a timeline using start/end date fields, dependencies, and milestones. Calendar View – Display records based on date fields, with drag-and-drop rescheduling. Gallery View – Visual cards featuring images, attachments, and selected record fields. Timeline View – Display records chronologically across days, weeks, months, or years. Form View – Create forms connected directly to Custom Objects for record creation and updates. Map View – Plot records geographically using address or location fields. Hierarchy/Tree View – Visualize parent-child relationships and associated Custom Object records. Essential Functionality Multiple Saved Views: Create unlimited views for each Custom Object. Personal & Shared Views: Allow individual users or teams to save their own layouts. Custom Filters & Sorting: Configure independent filters, sorting, and grouping for each view. Field Visibility: Choose which fields appear in each view. Drag-and-Drop Editing: Update record properties directly from Kanban, Calendar, Gantt, and other applicable views. Inline Editing: Modify records without opening their detail pages. Permissions: Control who can create, edit, share, or access specific views. Real-Time Synchronization: Changes made in one view should immediately reflect across every other view. Associations: Allow views to display and filter records using related Contacts, Companies, and other Custom Objects. ## Why This Matters GoHighLevel is evolving beyond a traditional marketing CRM into a platform capable of supporting entire business operations. Custom Objects are a major part of that evolution, but storing custom data is only half the solution. Users also need flexible ways to interact with that data. For example: Education: Student applications in Kanban, class schedules in Calendar, student records in Grid. Real Estate: Properties in Gallery, listings on Map, transactions in Kanban. Healthcare: Patient records in List, Recruitment: Candidates in Kanban, hiring schedules in Gantt. Manufacturing: Inventory in Grid, production schedules in Timeline. Project Management: Tasks in List, deadlines in Gantt, progress in Kanban. All of these workflows could operate on the same Custom Object infrastructure

Make appointment owner details available as custom values (in workflows and connected email builder) This way in emails/text/webhooks, the appointments owner details and name can be used in workflows (all features) and emails that are sendout. And the contact ownership remains untouched.

At minimum, role permissions so certain objects can be restricted to admin. Ideally, user permissions to control object visibility by user.

I would like to suggest adding the ability to restrict Custom Objects based on Roles and Permissions inside HighLevel. As more businesses use Custom Objects to manage important data, not every user should have access to every object or every record. Different team members may need different levels of access depending on their role. For example, a sales user may need access to lead-related Custom Objects, while a manager may need access to financial, operational, or reporting-related Custom Objects. In some cases, certain users should only be able to view records, while others should be able to create, edit, delete, or manage them. The ideal improvement would be: Admins can control which roles can access each Custom Object Admins can set view, create, edit, delete, and manage Permissions can be assigned by role or individual user Sensitive Custom Objects can be hidden from unauthorized users Permissions apply consistently across desktop, mobile app, workflows, reporting, and contact records This would be very useful for agencies, sales teams, real estate teams, medical clinics, service businesses, SaaS companies, and any organization using Custom Objects to manage private or role-specific data. Adding role-based permissions for Custom Objects would improve data security, reduce accidental changes, protect sensitive business information, and make Custom Objects more practical for larger teams.

With the new List Formatter action, we have greater ability to control list fields. Unfortunately, we are unable to create list fields ourselves. The current way I create lists is using a comma seperated list in a text field. List fields would drastically reduce the amount of text formatting required to remove items from such lists, and would make formatting more consistent.

When I add an association between two records, GHL opens a drop-down that searches through all the records of the other object (attached screenshot). It's quick and prevents anyone from writing the name by hand. It works. I ask to be able to use that same search engine as a custom field within an object or an opportunity. Today it lives only on the associations screen. PROPOSAL A new type of field, “Related Record”. When creating it, you choose the destination object and whether it admits one value or several. It is created just like a multiple-selection dropdown, and its values are records of another object. As a field, it inherits what you already do with fields: it appears in forms and surveys, it merges into documents, emails and SMS, and the workflows read and write it like any other. HOW WOULD THE FIELD WORK? * It can be created both in custom objects and in opportunities. * The field goes through the records of the destination object and provides them in the search engine in a multi-selection drop-down view. * A filter can be added to the drop-down list that shows by a condition on the fields of the destination object, in the style of filters that already exist in the views. For example: show the records of the custom object “materials” that meet the condition field status is “in use” and leave out those that are out of stock, removed or expired. * automatic association. When you select one, the association is created automatically. If the custom field is in opportunity, and reference to the “Material” object, the opportunity-material association would be created * Live at the level of a custom field, with everything that drags: being able to use it and print it in forms, merge it into documents and workflows. EXAMPLE Tattoo studio. Three objects: Session, Materials and Inks. Each session consumes different materials and inks, and the signed consent must list them. It's a health requirement, not a whim of reporting. Session would have two multiple-selection fields, Materials Used and Inks Used, and the document would print: Used materials: {{custom_objects.session.used_materials}} Used inks: {{custom_objects.session.used_inks}} Today the relationship can only be an association, and the document comes out empty: there is no way to go through the associated records in a template. AT PRESENT I ended up creating a private integration and an external service that reads the logs by API and rewrites the options of a drop-down. You have to issue a token with read and write permissions on objects, custom fields, opportunities and associations, and leave it alive on a server outside GHL. (2nd image) It works and I keep it without problem. I write this suggestion because from the outside I sense that much of the work you have already done, even if I don't know the real implications of integrating it. WHAT DOES IT UNLOCK A workflow that reads a field with records inside can go through them and act on them: * Inventory. Subtract stock when a session, order or visit consumes them, and mark out of stock when it reaches zero. *Improved traceability through automatic associations. * Measure consumption. Add up the amount spent on a job based on the records it has attached. * Maintenance. Count uses of a tool and launch your review. Each sector has its version, and they all end up in the same thing: interrelated objects and automations that need to cover that relationship. Thank you for working with personalized objects this past year, the progress is very noticeable. This is the only piece that keeps forcing us to leave the product. Happy to give more detail or show the full case. Cheers to the team!

We need to be able to add custom objects on the mobile app at the time service.

It would be great if pages & funnels could access Custom Objects and display them on the page, probably as a gallery. In our case, we're going to be showing properties. We'll have a featured image that we'd want to be displayed in a gallery, with some basic information from the custom object. Then the user can click that item to see the full details about that custom object (property).