What is the actual purpose of the objectTypes field in Custom Workflow Actions?

[MikaelSantilio]

Hi everyone,

I’m building a Custom Workflow Action and defined the following in the action schema:

"objectTypes": ["TICKET"]

My expectation was that this field would make the action visible and usable only inside Ticket workflows. However, the action still appears in other workflow types (such as Contact workflows) and even allows opening the configuration screen normally.

This made me unsure about the real behavior of objectTypes. What is the intended purpose of the objectTypes field?

• Is it supposed to restrict the action so it only appears for the specified object type?

• Or is it only used for backend/internal validation and not enforced in the workflow editor UI?

If anyone can clarify the expected behavior or confirm whether this is a current limitation/bug in the editor, I’d appreciate it.

Thanks!

[RubenBurdin · Accepted solution]

Hi  @MikaelSantilio , your intuition is right, and your confusion is shared by many devs who hit this for the first time.Today, objectTypes in a Custom Workflow Action schema is not a UI-level restriction. It does not prevent the action from appearing in other workflow types, and it does not block users from opening the configuration screen in, say, Contact workflows. What you’re seeing is expected behavior, not a misconfiguration on your side.

The intended purpose of objectTypes is primarily context definition and backend validation, not editor filtering. It tells HubSpot what object context the action expects at execution time. When the workflow actually runs, HubSpot uses this metadata to validate inputs, map object properties correctly, and decide whether the action can execute for the enrolled record. The workflow editor UI does not currently enforce or hide actions based on objectTypes.

In other words:

objectTypes does not control where the action is visible.

It does describe what object types the action is compatible with when executed.

If the workflow runs on an incompatible object, you’ll typically see execution errors or skipped actions rather than the action being blocked upfront.

This is a known limitation of the editor, not a bug in your app. HubSpot has been gradually improving custom action ergonomics, but as of now, there’s no supported way to truly scope visibility of a custom action to only Ticket workflows. Defensive validation inside your action code is still required.

The closest official reference is the Custom Workflow Actions schema documentation, which describes objectTypes but does not promise UI enforcement: https://developers.hubspot.com/docs/api/automation/custom-workflow-actions

You’re reasoning about it correctly. The platform just doesn’t enforce that contract visually yet.

[Victor_Becerra]

Hi Mikael @MikaelSantilio 
Thanks for raising this — it’s a great question.

I’m going to bring in a few community members who’ve spent a lot of time working with custom workflow actions and schema behavior. They may be able to shed some light on whether objectTypes is meant to act as a true UI-level restriction or if it’s currently more of an internal validator.

Hi @nickdeckerdevs1 @MichaelMa @danilo_amorim  Have any of you run into this before or know how objectTypes is actually enforced? Would love to hear your perspective.

Appreciate you surfacing the question — hopefully we can get you a clear answer.
Victor