What can custom coded actions do in HubSpot workflows?
Short answer
A custom coded action runs your own JavaScript inside a workflow, which lets it do four things no native action does: ... call an API, ... read the records associated to the enrolled one, do arithmetic between two properties, and aggregate many records into one message. It needs Data Hub Professional, now called Data Hub Professional. Each run is per enrolled record, inside a 20 second window, and any secret it uses is readable by anyone who can edit the workflow.
Read the whole answerShow less
What a spec looks like
The nine sections, and the files
Every spec follows the same nine sections, so a team reads one and knows how to read all of them.
- Outcome, when to use it and when not to
- Prerequisites: properties, lists, tiers, with the JSON to create them
- Enrollment and re-enrollment, then every step with its parameters
- Known pitfalls, a test plan, variants, and the YAML build spec
PDF, Markdown, properties JSON, workflow JSON, custom code where used. Test plan and known pitfalls in every spec.
Each spec states its minimum tier. The 12 free ones open in full, the others show their public preview.
The 80 specs, in build order
Data transformation and formatting
Lookup tables and string cleanup that turn free text into one standard value the rest of the portal can filter on.
What each spec doesHide
Show the 12 other specs in this groupShow fewer
Cross-object lookups and associations
Code that searches the CRM, reads the records associated to the enrolled one, and writes or flags the link.
What each spec doesHide
Show the 21 other specs in this groupShow fewer
External APIs and webhooks
Outbound calls to a product API, a vendor or a chat tool, with the secret, the timeout and the failure path handled.
What each spec doesHide
Show the 4 other specs in this groupShow fewer
Scheduling and date math
Scheduled runs that compute an elapsed time, sweep a database on a cadence, or aggregate a week into one message.
What each spec doesHide
Show the 15 other specs in this groupShow fewer
Scoring and calculations
Weighted scores, counters, currency and commission math, and alerts that compare today against a rolling baseline.
What each spec doesHide
Show the 8 other specs in this groupShow fewer
The 3 things that break this, and how the specs stop them
A workflow secret is readable by everyone who can edit the workflow
Storing an API key as a workflow secret keeps it out of the visible action configuration, but it does not hide it from your colleagues.
Check in Settings who can view and edit workflow secrets, and keep that list as narrow as the credential deserves. Rotating a key on the vendor side breaks every future run, with no retry of the calls that already failed.
How the specs stop itShow less
A 200 response is not proof the payload landed
An endpoint that returns 200 and then rejects the payload in its own response body shows up as a success unless the code reads the body too, not just the status.
The same trap sits inside the CRM: a failed fetch that returns an empty list reads as a real zero. Every spec here outputs a distinct error code instead, so a failure shows as a failure in workflow history.
How the specs stop itShow less
Rate limits pause the action and everything after it
A coded action runs per enrolled record, in 20 seconds, in 128 MB, and you set a rate limit per action.
Hit that limit and the action pauses, along with every step that follows it. The CRM Search API called from inside the code is throttled separately, so a bulk import can starve a detection workflow that works fine at normal volume.
How the specs stop itShow less
What this bundle builds
Eighty specs that all share one thing: a step where the native action list runs out and you write code instead. They come from the four jobs that keep hitting that wall. Turning free text into one standard value, because a lookup table of country spellings cannot live in a branch. Reading the records associated to the enrolled one, because a deal cannot see its own line items. Talking to something outside the portal, because there is no native action for your product API. And doing arithmetic, because a workflow branch compares two properties but never subtracts one from the other.
This suits an in-house operations owner who already has Data Hub and is not sure what it actually buys them, and an agency that keeps rewriting the same domain matching code on every portal. The five components map to the five shapes that code takes in a workflow: transformation and formatting, cross-object lookups and associations, external APIs and webhooks, scheduling and date math, then scoring and calculations. Every spec names its secrets, its input fields and its output fields before the first line of code.
Read the restShow less
How the pieces fit together
Start with the formatting specs. They need no token, no secret and no API call, so you can build one in twenty minutes and see the pattern: inputs in, lookup table, output fields, error branch. That build teaches you the shape of every other spec in the pack.
Cross-object work comes next, because it adds the first dependency: a private app token with read access on the objects you search. Company association from email domain is the one to build first, since duplicate detection, the line item check and the association caps all reuse its search and its free-mail exclusion list.
External calls come third, once you have somewhere safe to keep a secret and a convention for failure. Scheduling sits fourth: it reuses the earlier code but multiplies the execution count, which is where rate limits start to bite. Scoring comes last because a score is only as honest as the properties feeding it, and those properties are what the first three components clean up.
What you get
- 80 specs, each with outcome, prerequisites, enrollment, steps, known pitfalls, a test plan and variants
- Each spec ships as PDF and Markdown
- Properties JSON, 125 properties across contacts, companies, deals, tickets, products and nine custom objects
- Workflow JSON for all 80, in Automation API format, switched off on import
- 80 custom coded actions as JavaScript files, each with its inputs, outputs and secrets named in the header
- A test plan per spec, including the forced-failure step that proves the error path works
- Install in one click for Full and Agency buyers
Who it is for, and who should skip it
Buy this if your portal already has Data Hub Professional or Enterprise and the licence is underused, or if you build on client portals and keep rewriting the same normalization and matching code. You get value in the first hour from the formatting specs alone.
Skip it if you do not have Data Hub. Nothing here runs without the custom code action, and buying it to find out is an expensive way to read a tier table. Take the native-only bundle instead. Skip it too if you want one specific outcome rather than a toolkit: a single bundle, or the full library, will fit better than eighty specs you did not ask for.
Questions admins ask
Do I need Data Hub Professional to use a custom code action?
Yes. The custom code action is gated to Data Hub Professional or Enterprise, now named Data Hub. Every spec in this pack uses one, so Starter and plain Professional portals of the other hubs cannot build them as written. Several specs carry a documented no-code alternative in their Variants section, and the native-only bundle collects 40 specs that need no code at all.
How many custom code executions do I get per month?
The specs in this pack disagree on this point and say so openly. The limits that are documented and that you can see yourself are the 20 second runtime, the 128 MB memory ceiling, and the rate limit you configure per action. Treat any monthly allowance figure as something to confirm against your own subscription before you schedule a daily sweep across the full database.
What happens when my code throws an error?
Nothing silently succeeds. Each spec catches the error and returns a result code plus a truncated error message as output fields, so the run shows as a failed execution in the workflow History tab. The branch that follows reads that code and routes to a task or an alert instead of treating a missing value as a clean result.
Can a workflow loop over several records and send one message?
Not with native actions. A standard workflow enrolls and acts per record, so fifty closed deals produce fifty notifications. The weekly digest spec does the aggregation inside the code: it queries the search endpoint for the date range, sums the amounts, formats one string and posts it once. At volume the query needs pagination, not a single unpaginated call.
Where do I put an API key that the code needs?
In a workflow secret, referenced from the code as an environment variable, never pasted into the code body. Every spec here that calls something external names its secrets in the header comment of its code file, so you know what to create before you build. A missing secret fails the action immediately rather than sending an unauthenticated request.
Read 12 complete specs before you pay.
One per category, same format as the paid ones. Email only, no card.
We email the link, then a short note when specs change. Nothing else.
Here it is. Download the pack now (.zip) The link is in your inbox too.
Browse the library