Domain Task 📋

Executes a provider-agnostic integration action via the Vertical Integrations framework.

Node type: domainTask Category: Integration Actor: domainTask (2 threads)

---

Description

The Domain Task provides a unified interface to domain-specific integrations — CRM, HR, payment, and other vertical platforms. Instead of writing direct API calls for each provider, you select a domain action (e.g., "Create Contact") and a domain connection (your specific provider like Salesforce or HubSpot), and the engine maps the call to the provider's API automatically.

This means:

• You can switch providers without changing workflow logic
• The same workflow works with Salesforce, HubSpot, Zoho CRM, etc.
• apptor flow normalizes field names across providers

---

Properties

Property	Type	Required	Description
domainActionId	domainActionSelect	Yes	The action to perform (e.g., CREATE_CONTACT, UPDATE_DEAL)
domainConnectionId	connectionSelect	Yes	The integration connection (provider + credentials)
integrationId	string	No	Integration definition ID
providerMappingId	string	No	Field mapping configuration ID
versionId	string	No	Specific version of the integration to use

---

Available Domain Actions

Actions are organized by domain. Common ones include:

CRM Domain

Action	Description
CREATE_CONTACT	Create a new contact/lead
UPDATE_CONTACT	Update an existing contact
GET_CONTACT	Retrieve contact by ID or email
CREATE_DEAL	Create a new deal/opportunity
UPDATE_DEAL	Update deal stage or properties
LIST_CONTACTS	Search/list contacts

HR Domain

Action	Description
CREATE_EMPLOYEE	Onboard a new employee
UPDATE_EMPLOYEE	Update employee record
GET_EMPLOYEE	Retrieve employee by ID
LIST_EMPLOYEES	Search employees

Payment Domain

Action	Description
CREATE_CUSTOMER	Create billing customer
CREATE_CHARGE	Charge a customer
CREATE_INVOICE	Generate invoice
GET_PAYMENT_STATUS	Check payment status

---

Inputs

The Domain Task accepts workflow variables that map to the domain action's required fields:

domainActionId: CREATE_CONTACT
domainConnectionId: int_salesforce_prod

The engine uses the providerMappingId to map workflow variables to the provider's API fields. For example, {firstName} + {lastName} → Salesforce FirstName + LastName.

---

Outputs

Variable	Type	Description
{domainTaskResult}	object	The normalized domain object returned by the provider
{domainTaskId}	string	The provider's ID for the created/updated record

Provider-specific IDs are also accessible: {domainTaskResult.id}, {domainTaskResult.email}, etc.

---

Connections

Connection	Description
sequenceFlow (incoming)	Arrives from previous node
successFlow	Domain action completed successfully
errorFlow	Domain action failed
timeoutFlow	Request timed out

---

Example: CRM Contact Creation

{
  "nodeId": "crm-create-contact",
  "name": "Create Contact in Salesforce",
  "nodeType": "domainTask",
  "properties": {
    "domainActionId": "CREATE_CONTACT",
    "domainConnectionId": "int_salesforce_prod"
  }
}

Before this node, workflow variables {firstName}, {lastName}, {email}, {phone} are set. The engine maps them to Salesforce contact fields via the configured mapping.

After this node: {domainTaskId} contains the Salesforce Contact ID.

---

Configuring Domain Connections

Domain connections are configured in the Connections page of the UI:

1. Navigate to Connections → Add Connection
2. Select a domain (e.g., CRM) and provider (e.g., Salesforce)
3. Enter authentication credentials (OAuth or API key)
4. The connection appears in the domainConnectionId dropdown in the designer

---

Provider Support

The vertical integrations framework supports adding new providers without changing workflow logic. Currently supported providers depend on your apptor flow deployment — check the Connections page for available providers.

---

Best Practices

• Use Domain Task instead of direct REST API calls when a domain integration is available — it's more maintainable and provider-agnostic
• Connect errorFlow and log the error for monitoring
• Set a timeout — external CRM/HR APIs can be slow
• Test with a sandbox/test account connection before using production credentials
• Use {domainTaskId} to store the provider record ID for future updates in the same workflow or via other workflows