Custom Objects

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

The current maximum of 10 custom objects per location is too restrictive for businesses that use HighLevel as a comprehensive CRM and long-term client management platform. I am building a financial services CRM that needs to manage multiple repeatable relationships and records, including employment history, properties, mortgages, liabilities, assets, vehicles, credit history, business relationships, insurance policies, lending opportunities, and other financial records. These are fundamentally different data entities and should not be forced into Contact custom fields or combined into unrelated objects simply because the system has reached a 10-object limit. I have already reached the maximum of 10 custom objects while building the core architecture, before completing important areas such as P&C insurance, life insurance, annuities, investment/retirement accounts, and additional lending records. Please consider significantly increasing the custom object limit, ideally with a higher or scalable limit based on plan level or as a paid add-on. Even increasing the limit to 25, 50, or allowing additional object capacity as an add-on would make HighLevel much more suitable for advanced CRM implementations. HighLevel already provides powerful custom fields, associations, workflows, APIs, and AI capabilities. Allowing more custom objects would make these capabilities substantially more valuable for businesses that need relational and repeatable data structures. This limitation is currently affecting my ability to continue building my business architecture inside HighLevel, even though I would prefer to keep HighLevel as my primary CRM platform. Thank you for considering an increase to the custom object limit.

Custom field cannot be updated, old customer coming in again different required, please update it

Problem When creating a Custom Object, the primary display field can only be a single-line text field. There is no Auto Number option, so every record has to be named by hand or by a workflow. This forces a bad trade-off: Mark the field as unique and you cannot store two records that legitimately share that value — for example two batches of the same product reference, where the batch number is what actually needs to be traced. Leave it not unique and records end up with duplicated or inconsistent names, which breaks list views, search and reporting. In our case (a tattoo studio with health and traceability records) we hit this twice: once with session records, once with materials. Both are high-volume objects where a human-typed identifier is a guaranteed source of errors. Proposed Add Auto Number as a field type for the primary display field, with: a configurable prefix (SES-, MAT-), a configurable starting number and padding, uniqueness enforced by the system instead of by the user. This already exists for other record types in the platform, so the concept is not new to users. Also, please expose it through the API POST /objects/ currently rejects anything other than TEXT in primaryDisplayPropertyDetails.dataType: {"message":["primaryDisplayPropertyDetails.dataType must be one of the following values: TEXT"], "error":"Unprocessable Entity","statusCode":422} Agencies that provision sub-accounts programmatically cannot create properly-keyed objects today; everything has to be finished by hand in the UI. Why it matters The primary field cannot be changed after creation. Getting it wrong means rebuilding the object and recreating every custom field on it — in our case 69 fields. A one-line choice at creation time has a very expensive mistake attached to it.

Payments & Invoicing aren't supported with custom objects. For family and team memberships, the subscription belongs to the account (a custom object record), not just the payer's contact. Please allow associating a subscription/invoice with a custom object record, and workflow triggers like "Subscription payment failed" that can update the associated record.

We store memberships as a custom object associated to contacts. We need to filter contacts by fields on their associated record, e.g. "contacts whose associated Membership Account has Status = Past Due," in Smart Lists, workflow If/Else conditions and merge fields. Today we have to copy those values onto every contact as tags just to target them.

Creating a custom object schema requires an agency token, and association limits (e.g. "one Account Holder per record") can only be set in the UI. Please allow both with a sub-account Private Integration Token (with the right scopes), so a setup can be scripted, versioned and repeated across sub-accounts without manual clicks.

RecordCreate/RecordUpdate and RelationCreate/RelationDelete events are only delivered to Marketplace apps. Businesses building their own integration with a sub-account Private Integration Token can't receive them, so we have to build a workflow with a Custom Webhook action for every object as a workaround. Please allow a sub-account (PIT) to register a webhook URL for object record and association events, with a signing secret.

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)

We need an option for custom fields can not be used to sending out data. For example we send out a survey with the chronic conditions, we want to ensure this field can never be pre-populated in an outgoing message. This would really be for HIPPA compliance. For example the data can come into the system it just can not go out. So if we could have some sort of one-way lock this way a user can not accidently add the wrong custom field.