Integrations
Automation Connectors
This page documents how OrcaPulse uses automation connectors in the current project: communication providers, CRM and webhook integrations, channel connections, onboarding setup flows, and the way workflow steps depend on those external resources at runtime.
What Automation Connectors covers
In the current OrcaPulse project, connectors are not treated as a separate abstract framework. They show up as the practical resources workflows and onboarding need in order to operate: phone numbers, email providers, CRM connections, webhook endpoints, WhatsApp accounts, assistants, voices, and social integrations.
This page is about that real operating pattern, where connectors exist to unlock actions, message delivery, sync steps, and source capture across the product.
Connector types in the current project
The codebase already groups connector-like resources into a few clear categories. Some are communication connectors such as phone, voice, email, and WhatsApp. Others are system connectors such as CRM and webhook integrations. Others are source connectors, especially the social and channel integrations that bring demand into OrcaPulse.
Together, these make up the operational dependency layer around workflows.
Communication connectors
Phone numbers, voices, email providers, WhatsApp accounts, and templates are treated as resources workflows can attach to specific steps.
Data-system connectors
CRM connections and webhook integrations give workflows ways to import, export, and sync lead data with external systems.
Channel connectors
Social and WhatsApp integrations act as source-side connectors that feed demand into the same operating layer as workflows and review surfaces.
- Communication layer: voices, phone numbers, email providers, templates, and WhatsApp accounts power actual outreach steps.
- System sync layer: CRM and webhook integrations connect workflows to downstream tools and external automation.
- Capture layer: social-media and channel integrations bring inbound activity into the same lead-ops environment.
Onboarding and setup flow
The onboarding experience already reflects the connector model directly. It checks Gmail status, social connections, current phone numbers, phone integrations, email providers, and CRM connections, then guides the user toward missing setup only when the chosen workflow path actually needs those resources.
This means connectors are introduced in context instead of forcing the user to configure every possible provider before they can do anything useful.
- Context-aware checks: onboarding only pulls phone, email, or CRM resources when the chosen steps need them.
- Connector-first guidance: when a needed connector is missing, the UI sends the user to integrations or the relevant setup path.
- Mixed setup model: some connectors use OAuth, some use API keys, and some are internal resource records such as templates or phone numbers.
Workflow dependency model
The workflow builder treats connectors as step dependencies. SMS and AI call steps need phone or voice resources. Email steps need templates and providers. CRM sync needs a CRM connection. Webhook sync needs a webhook integration. WhatsApp steps need accounts and templates.
That makes connectors part of workflow validity, not just a background configuration tab.
- Step-bound dependencies: each action type pulls in the connector resources it needs to run.
- Activation impact: missing connectors can block useful execution even when the workflow structure itself exists.
- Reusable resources: the same connector or resource can support multiple workflows instead of being recreated each time.
Resource loading and selection
The current workflow builder loads connector resources lazily based on the step types present in the workflow. If the workflow contains email steps, it loads email templates and provider state. If it contains AI call steps, it loads assistants, voices, and phone numbers. If it contains CRM or webhook steps, it loads those connector lists too.
This is a useful architectural clue: OrcaPulse does not treat all integrations as one big static bundle. It resolves them as operational dependencies of the workflow being built.
- Lazy resource loading: connector lists are fetched only when matching step types are present.
- Unified resource selection: the builder uses the same pattern for SMS, email, voice, CRM, WhatsApp, and webhook resources.
- Cached connector state: webhook resources are even cached in the browser layer to reduce redundant fetches during editing.
Operational connector pattern
The connector model in OrcaPulse is operational rather than decorative. A connector is valuable only when it either brings data in, enables an action to go out, or makes a workflow step executable.
That is why CRM, webhook, phone, email, WhatsApp, and social integrations keep showing up across onboarding, workflow creation, runtime execution, and review surfaces. They are the edges where OrcaPulse meets the rest of the operating environment.
- Inbound role: connectors can feed leads or conversation activity into OrcaPulse.
- Outbound role: connectors can deliver messages, calls, CRM updates, or webhook events out of OrcaPulse.
- Execution role: connectors are what turn a planned workflow into one that can actually run in the real world.
Next steps
After Automation Connectors, the next useful integrations page is usually Calendar Booking, because scheduling is another downstream operational connector that fits naturally after CRM and webhook delivery.



