Extensibility & Customization

Relevant source files

The following files were used as context for generating this wiki page:

• backend/src/workflows/domain/action_entities.py
• backend/src/workflows/presentation/action_routes.py
• IMPLEMENTATION_REPORT_SPEC_WFL_003.md
• frontend/PHASES_8-15_COMPLETION_REPORT.md
• FRONTEND_PHASES_4_7_IMPLEMENTATION_SUMMARY.md
• DOCUMENTATION_SUMMARY.md

The GoHighLevel Clone platform is designed with a highly modular and extensible architecture, allowing for the addition of new automation capabilities, custom UI components, and third-party integrations. This extensibility is primarily driven by a Spec-First Domain-Driven Design (DDD) approach in the backend and a component-driven architecture in the frontend.

The system supports customization through dynamic configuration schemas, pluggable action types, and a flexible visual builder. Developers can extend the platform by defining new ActionTypes, creating custom React Flow nodes, or implementing new integration connectors.
Sources: IMPLEMENTATION_REPORT_SPEC_WFL_003.md, FRONTEND_PHASES_4_7_IMPLEMENTATION_SUMMARY.md

Backend Action System Extensibility

The workflow automation engine is built to be "Action-agnostic," meaning the core engine handles the orchestration while specific business logic is encapsulated within individual action implementations.

Pluggable Action Architecture

New actions can be added by extending the ActionType enumeration and providing a corresponding ActionConfig validation schema. The system currently supports over 25 action types categorized into Communication, CRM, Timing, Logic, Internal, and Integration.
Sources: IMPLEMENTATION_REPORT_SPEC_WFL_003.md, FRONTEND_PHASES_4_7_IMPLEMENTATION_SUMMARY.md

The diagram above shows the relationship between core Action entities and the extensible ActionType/Config system.
Sources: backend/src/workflows/domain/action_entities.py:1-50, IMPLEMENTATION_REPORT_SPEC_WFL_003.md

Custom Action Integration

To add a new custom action to the backend, the following components must be implemented or updated:

• Domain Layer: Define the new ActionType and validation rules within ActionConfig.
• Infrastructure Layer: Ensure the ActionModel can store the custom configuration (typically via JSONB).
• Application Layer: Update the AddActionUseCase to handle any specific linking logic required by the new type.
  Sources: IMPLEMENTATION_REPORT_SPEC_WFL_003.md

Frontend Customization & Builder Extensibility

The frontend uses a dynamic form generation strategy and a custom node system in React Flow to allow for rapid expansion of the Visual Workflow Builder.

Dynamic Form Generation

The ConfigurationPanel generates UI forms dynamically based on a StepDefinition. This allows developers to add new triggers or actions to the sidebar by simply updating the step-types.ts constant file without rewriting form logic.
Sources: FRONTEND_PHASES_4_7_IMPLEMENTATION_SUMMARY.md, frontend/PHASES_8-15_COMPLETION_REPORT.md

Configuration Field Type	Component Used	Purpose
text	Input	Single-line text settings
textarea	Textarea	Multi-line content (e.g., Email body)
select	Select	Single option selection
toggle	Switch	Boolean logic (True/False)
tags	Select	Multi-tag assignment
datetime	DatePicker	Specific scheduling
Sources: FRONTEND_PHASES_4_7_IMPLEMENTATION_SUMMARY.md

Custom React Flow Nodes

The canvas supports custom StepNode components that are color-coded and styled based on their type. Developers can create specialized nodes for complex logic like Split Test or Wait Until.
Sources: FRONTEND_PHASES_4_7_IMPLEMENTATION_SUMMARY.md

The flow shows how definitions in the sidebar drive the canvas nodes and the dynamic configuration forms.
Sources: FRONTEND_PHASES_4_7_IMPLEMENTATION_SUMMARY.md, frontend/PHASES_8-15_COMPLETION_REPORT.md

Integration & Webhooks

Extensibility is further enhanced through the Internal and Integration action categories, specifically via Webhooks and Custom Code.

Webhook Extensibility

The platform supports both inbound and outbound webhooks:

• Inbound: A webhook.received trigger allows external systems to initiate workflows.
• Outbound: The webhook.call action allows the platform to push data to external APIs (e.g., Zapier, Make, or custom endpoints) using POST, GET, PUT, or DELETE methods.
  Sources: FRONTEND_PHASES_4_7_IMPLEMENTATION_SUMMARY.md, IMPLEMENTATION_REPORT_SPEC_WFL_003.md

Custom Merge Fields

The system supports a placeholder pattern {{contact.field}} for dynamic data insertion. This system is extensible, allowing custom fields defined in the CRM module to be used as merge fields across all communication actions.
Sources: FRONTEND_PHASES_4_7_IMPLEMENTATION_SUMMARY.md

Conclusion

The GoHighLevel Clone's extensibility is rooted in its decoupled architecture. By separating action definitions from the execution engine and utilizing dynamic UI generation in the frontend, the platform allows developers to customize the automation experience and integrate with any external ecosystem with minimal core code modifications.
Sources: DOCUMENTATION_SUMMARY.md, IMPLEMENTATION_REPORT_SPEC_WFL_003.md