How to Show and Hide Elements on Button Click in GoHighLevel

How GoHighLevel show and hide actions work

A show and hide interaction connects two page elements: a trigger and a target. The trigger is usually a button. The target is the section, row, column, text block, image, form area or other element that changes visibility.

The custom ID acts as the connection point. The target receives an ID such as more-details, and the button action refers to that exact value. The display setting then tells the page builder how the target should render when it becomes visible, such as block, flex or inline-block.

Set up the target element first

Start with the element that should appear or disappear. Configuring the target before the button reduces the chance of connecting the trigger to the wrong section.

1. Choose a meaningful target

Select the smallest useful unit of content that should change state. For example, an FAQ answer can be hidden without hiding the question, and an optional form area can be revealed without moving the entire form.

Avoid hiding a large parent section when only one paragraph or field group needs to change. Larger targets can create unexpected spacing, layout shifts and a less predictable mobile experience.

2. Add a unique custom ID

1. Open the funnel or website page in the GoHighLevel builder.
2. Select the target element.
3. Open its advanced settings.
4. Find the custom ID field.
5. Enter a short, unique ID such as faq-answer-pricing or optional-contact-fields.

Use a consistent naming style with lowercase letters, numbers, hyphens or underscores. Do not use spaces. The ID must match the value used by the button action exactly, including spelling and punctuation.

Uniqueness matters because the action needs one clear target. If multiple elements use the same ID, the page may behave inconsistently or affect an element other than the one intended.

3. Select the visible display type

In the target element’s advanced settings, choose the display type that matches the layout when the element is visible. Block is commonly appropriate for a full-width text or content section. Flex can be appropriate when the element contains a flex-based arrangement. Inline-block may suit a smaller element that sits alongside other content.

The correct choice depends on the surrounding layout. If the target is part of a row with columns, selecting a display type that conflicts with the original design can change alignment, width or spacing after the click.

Configure the button action

4. Add or select the trigger button

Add a button near the content it controls, or select an existing button. Its position and label should make the relationship obvious. Labels such as Show pricing details, Read the full answer or Add project details communicate a result more clearly than a generic label such as Click here.

5. Open the button action settings

With the button selected, open the button settings and locate the action, on-click or equivalent interaction control. GoHighLevel interfaces can change over time, so the exact label or location may vary by builder version. Look for the setting that lets the button show or hide an element by its identifier.

6. Reference the target ID

1. Choose the show, hide or toggle action available for the button.
2. Enter the target’s exact custom ID.
3. Check whether the action is configured to show the element, hide it or switch between both states.
4. Save the page before testing.

Do not add a leading symbol or extra spaces unless the GoHighLevel field specifically requires them. The safest approach is to copy the ID from the target settings and compare it character by character with the button configuration.

Test the interaction as a visitor

Builder mode is not enough to validate a show and hide interaction. Save the page and test it in preview mode or in the published page, depending on the workflow available in your account.

Check the initial state

Confirm that the target is hidden when the page first loads if that is the intended experience. Look at the space around the target, not only the target itself. An empty gap, unexpected border or background may remain if the parent container has its own styling.

Check the click result

Click the button and verify that the correct element appears. Check that the content is readable, that the layout does not overlap other elements and that the page does not jump farther than expected. If the button is intended to toggle the content, click it again and confirm that the target returns to the expected hidden state.

Check mobile behavior

Test the page at mobile, tablet and desktop widths. A target that looks correct on desktop may become too wide, create excessive padding or disrupt a stacked mobile layout. Also confirm that the trigger is easy to tap and remains close enough to the content it controls.

Use show and hide for a clear information hierarchy

Hiding content should reduce unnecessary cognitive load, not conceal information that visitors need to make a decision. A useful rule is to keep the primary answer or action visible and place supporting detail behind the button.

For an FAQ, display the question and reveal the answer. For a product section, show the main benefit and reveal technical specifications or secondary details. For a form, ask for the minimum information needed first and reveal additional fields only when the visitor chooses a relevant option.

Avoid using the interaction to hide essential terms, costs, eligibility requirements or other information that should be available before a user proceeds. Progressive disclosure works best when the hidden content is useful but not required for the first decision.

Practical scenarios

Expandable FAQ answer

Imagine a service page with six common questions. Each answer can be assigned its own ID, such as answer-timeline. A button beside the question can reveal the corresponding answer. The page remains shorter initially, while visitors can access detail when they need it.

Optional form fields

Imagine a lead form that asks whether a visitor needs implementation support. If the visitor selects yes, a button can reveal additional project-detail fields. The form should still explain what information is being requested, and the revealed fields should not be required for visitors who do not need that service.

Additional product detail

Imagine a funnel that presents a concise offer summary above the main action. A button labelled View technical details can reveal the supporting specifications below. The target should be close to the button so the relationship remains clear after the page expands.

Operational rules for reliable interactions

Observation: A button label should describe the content state it creates, not merely the action of clicking.

Observation: The smaller the target element, the easier it is to test, maintain and explain.

Observation: A hidden element still affects the user’s experience if its container leaves spacing, styling or a confusing visual gap.

Observation: An interaction is not complete until its initial state, changed state and mobile state have all been checked.

When to use another approach

Show and hide is appropriate for lightweight page interactions. It may not be the right solution when the content needs its own URL, must be indexed as a separate page, depends on complex application logic or requires records to be saved and processed.

If the interaction is part of a larger lead-management process, clarify what should happen after submission. The page interaction may reveal fields, but a reliable CRM process still needs clear ownership, consistent data and a defined follow-up state. For broader workflow design, see CRM consulting or the wider systems and automation services available from ConsultEvo.

A simple decision sequence

1. Define the user decision: What does the visitor need to decide or understand?
2. Separate primary from supporting content: Keep the essential information visible and hide only secondary detail.
3. Choose the target: Select the smallest element that should change state.
4. Assign the ID: Use one unique, readable identifier.
5. Configure the trigger: Point the button action to the exact ID.
6. Test all states: Check initial, visible, toggled and mobile behavior.
7. Review the outcome: Remove the interaction if it adds friction without improving clarity.

This sequence keeps the work process-first. The GoHighLevel setting is only the implementation detail. The quality of the page depends on whether the interaction represents a clear user need and behaves consistently after publication.