Scope requirements
Scope requirements
Action types
Each workflow specification consists of a list of actions. Each action contains a set of required properties:actionId: a unique ID that identifies this action, provided as a string.actionTypeId: a predefined value that specifies the action type (e.g.,"0-1"designates aDELAYaction). A list of actions and their associatedactionTypeIdis provided in the section below.actionTypeVersion: a number that designates the version of the action. For all built-in action types (e.g., a delay, email notification, etc.), theactionTypeVersionwill be0.connection: for non-branching actions, this property is an object that specifies the subsequent action, and contains two nested properties:edgeType: to proceed directly to the next action, this property should be set to"STANDARD". If you have a branch in your workflow, you can go to an action in a different branch by setting theedgeTypeto"GO-TO".nextActionId: the ID of the subsequent action in the workflow.
type: for non-branching actions, this should be set toSINGLE_CONNECTION.fields: an object that specifies the data required by the action (e.g., how long to delay an enrolled object for aDELAYaction). The structure of this property depends on the action type. Consult the sections and example actions below for the fields each action type expects.
Action type IDs
The table below details the available action types along with the associatedactionTypeId.
- Branches and Go to actions do not have an associated
actionTypeId. - For integration actions, you can add the action to your workflow, then make a
GETrequest to/automation/v4/flows/{flowId}to retrieve theactionTypeId.
Note that some actions have the same type ID, such as Delay until a calendar date and Delay until a date property. These actions are split into their own table rows to match how they appear in the workflow action sidebar.
Action fields
Thefields property of your action depends on the corresponding action type.
- The actions available depend on your account’s subscriptions. Learn more about the available actions in workflows.
- To confirm the fields required for a specific action, you can create the workflow with that action using the workflows tool, then make a
GETrequest to/automation/v4/flows/{flowId}for that workflow.
In the example code blocks below, note that the
nextActionId field values are demonstrative, and should contain the ID of the next action in your particular workflow.Delay until a specific date or date-based property
The code below specifies a Delay until a calendar date action, but can also be used with a Delay until a date property action. Based on whether you’re delaying until a preconfigured date or a date-based property of the enrolled record, you’ll need to specify the sub-properties of thedate field accordingly:
- If you’re delaying until a specific calendar date, provide
STATIC_VALUEfor thetypesub-property, then provide the calendar date for thestaticValuesub-property as a unix timestamp. - To delay until a date-based property of the enrolled record, provide
OBJECT_PROPERTYfor thetypesub-property, then specify the property to use as thepropertyName.
Delay a set amount of time
The code below specifies a Delay for a set amount of time action.Send an automated marketing email to an enrolled contact
The action definition below sends an automated marketing email with an ID of12345678 to an enrolled contact.
Set property
The action definition below sets thehs_lead_status property to "IN_PROGRESS".
Create task
The action definition below creates an unassigned task:Create a new record
The action definition below creates a new deal and associates it with the contact enrolled in the workflow:Add an enrolled object to a static list
The action definition below adds an enrolled contact to a static list, specified as thelistId.
Remove an enrolled object from a static list
The action definition below removes an enrolled contact from a static list, specified as thelistId.
Branching actions
Branching actions differ from other actions in that they don’t follow the standard action structure. Branching action definitions don’t havefields or connection properties. There are two types of branching actions: list branch actions and static branch actions. Both types must also define a default branch using the defaultBranchName and defaultBranch properties.
List branch actions
List branch actions include alistBranches property that specifies a set of filter branches to segment enrolled objects. Each filterBranch is configured using the syntax and formatting outlined in the list filters documentation.
Static branch actions
Static branch actions include aninputValue definition, which supports different shapes for the input values of the branch. It also includes a list of staticBranches, which defines which actions come next in the branch.
Enrollment criteria
You can configure the conditions for objects to be enrolled in your workflow within theenrollmentCriteria property of your workflow specification.
- The data you specify varies based on whether your enrollment is event-based or list-based. You can specify the enrollment type by setting the
typeofenrollmentCriteriato eitherEVENT_BASEDorLIST_BASED. - You can specify the re-enrollment settings for objects enrolled in your workflow by setting the
shouldReEnrollfield totrueorfalse.
Event-based enrollment
Event-based workflows will enroll objects when specific events occur, such as when a form is submitted.- You can configure the criteria for which events will trigger enrollment by defining a list of
eventFilterBranches. EacheventFilterBranchdefinition specifies a qualifying event (e.g., a form submission) using aneventTypeIdthat corresponds to that event. - Most events will have the same values for the following fields:
operator:"HAS_COMPLETED"filterBranchType:"UNIFIED_EVENTS"filterBranchOperator:"AND"
eventTypeId that corresponds to the event you can configure for your workflow.
The example code below defines the
enrollmentCriteria to enroll contacts who successfully submitted a form:
Filter-based enrollment
Workflows with filter-based enrollment will enroll records when the configured criteria is met.- The criteria is configured by setting the
listFilterBranchfield of yourenrollmentCriteria, based on which objects should qualify for enrollment in your workflow. Within alistFilterBranch, you can define the specific filter criteria using a list offilterBranches. - Learn more about the syntax and formatting for defining a
listFilterBranch.
enrollmentCriteria below defines the criteria for when a contact’s City property is equal to Dublin: