HubSpot workflows are becoming more flexible with expanded support for event-based processes. Traditionally, workflows and their custom actions have relied on a specific “enrolled object” (contact, company, deal, ticket, etc.) to execute logic, which limits their usage when no object enrollment occurs. With the introduction of new workflow types that aren’t tied to a single enrolled object (such as event-based workflows), there is a need for custom actions to adapt accordingly.
To support these workflows, we’re introducing a new requiresObject boolean flag to extend support for "target objects" in custom actions on November 24th, 2025. This update addresses a long-standing limitation in HubSpot's custom action framework by allowing actions to function in workflows even when no object is enrolled. Additionally, the objectTypes field will now apply at the action level rather than the workflow level. This means each action within a workflow can independently specify which object type it targets. Actions will interpret the data according to the object type selected or, by default, the workflow’s enrolled object.
With these changes, custom actions will now present customers with a dropdown to select a “target object”. By default, this will be set to the workflow’s enrolled object, preserving existing behavior for current workflows.
How things worked before:
-
- Action definition: The
objectTypesfield determines which workflow object type the action is available for. - Execution payload: An
objectfield is included in the payload (with object type and ID) - Fetch options: The workflow’s
objectTypeIdis included in the request payloads
- Action definition: The
Because these elements always depended on the enrolled object, custom actions could not function in workflows that weren’t tied to an object type.
What's changing?
As mentioned above, we’re introducing a requiresObject boolean flag (defaulting to true) on all custom actions. When this flag is set to true, a target object will automatically be added to the action, allowing it to work with any object, not just the enrolled one. The workflow runtime will populate the object in the execution payload.
What does this mean for developers?
This change affects all custom actions built using the Custom Workflow Actions API or Developer Projects that include custom actions.
By default, all actions will have requiredObject: true, meaning the target object selector will appear in workflows. See example below:
Note: In the example of the custom action definition above, because the action includes objectTypes: [“CONTACT”], it cannot set requiresObject: false, as defining required objectTypes means the action depends on an object.
If your action does not need to receive a target object and you don’t want end users to see the object selector dropdown, you can set requiresObject: false in your custom action definition.
When is it happening?
This change goes into effect in 30 days on Monday, November 24th, 2025.
Questions or comments? Join us in the developer forums for a peer-to-peer discussion.