What actually gets built
Six things, all of them hands-on. If a job needs someone to open the API docs and the action log at the same time, it belongs here.
Workflow and lifecycle architecture
Enrolment logic that does what it reads like it does. Branching, delays, re-enrolment, and the lifecycle stage rules underneath — written down, versioned, and verified against the action log rather than the builder canvas.
Custom coded workflow actions
The logic HubSpot's action library cannot express. Serverless functions inside the workflow with real error handling, idempotency, and logs you can read when something goes wrong at 2am.
CRM data migration
Records, associations and history moved with a reconciliation you can defend. Counted before, counted after, every difference explained rather than rounded away.
Custom objects and associations
Schemas that model your business instead of bending deals into a shape they were never meant to hold. Association labels, limits, and the reporting that has to work on top.
Integration and webhook debugging
The job nobody wants: two systems that disagree, an API that accepts a payload and drops a field, a webhook that fires twice. Traced end to end until the cause is named, not patched at the symptom.
Private apps, scopes and serverless
OAuth scopes, private app credentials, serverless functions and the parts of the platform the UI does not expose — set up so the next person can understand them.
Three things found in real portals
All from live client work, all reproducible, all invisible from the HubSpot UI. Client details are withheld; the mechanics are not.
Workflows that had never fired
HubSpot's Lists API rejects an association-absence filter outright. The Workflows API accepts the same filter, saves it, and leaves it permanently inert — no error, no warning, nothing in the UI to suggest anything is wrong. Three workflows had been enrolling nobody. The working pattern is a list branch on IN_LIST with the action on the default path.
Routing branches feeding two pools
Three round-robin workflows branched four ways by region, then rotated into only two pools. Region routing was decorative and had been for as long as anyone could remember. Fixed by re-deriving the region map from actual record ownership, then repointing nine rotate actions across the three workflows.
Against a 240 hand-built baseline
A report definition nobody trusted, rebuilt independently and reconciled against a manual count. Four records apart, each one explainable. That is how a metric gets proven rather than asserted — and it is the difference between a dashboard people use and one they quietly work around.
How the work runs
Read the portal
Config, action logs, and what actually ran — not what the builder claims.
Name the cause
A finding is a hypothesis until behaviour confirms it. Config says what could happen; the log says what did.
Change it once
Where every caller routes through, not at the symptom the ticket named.
Verify against the portal
Read the change back. Some writes are accepted and silently dropped.
Frequently Asked Questions: Fractional RevOps, HubSpot, & Business Growth
Consulting tells you what to change. Engineering is the person who opens the workflow, reads the filter, works out why it has never fired, and rewrites it. In practice that means custom coded actions in the workflow builder, custom objects and association schemas, data migrations with reconciliation, private app and OAuth scopes, webhook debugging, and the parts of the API that the UI does not expose.
That is one of the most common jobs. HubSpot has failure modes with no error surface at all. Association absence is the sharpest example: the Lists API rejects a NOT_IN_LIST filter for it outright, while the Workflows API accepts the same filter, saves it, and leaves it permanently inert. The workflow looks right in the builder and enrolls nobody. The working pattern is a list branch on IN_LIST with the action on the default path.
Whichever is correct for the change. Some operations are only safe through the UI, some are only possible through the API, and some the UI will silently drop — multi-select report filters, for instance, can lose values on save, so the filter gets read back after writing. Every change is verified against the portal afterwards rather than assumed from the response.
Reconciliation, not optimism. Records are counted before and after, associations are censused rather than sampled, and any figure that moves has to be explainable. On one migration the target report came out at 236 against a 240 hand-built baseline — four records apart, each one accounted for. That is the standard: a number you can defend, not a number you hope is right.
Custom coded workflow actions need Operations Hub Professional or Enterprise. Custom objects need Enterprise on the relevant hub. Almost everything else — properties, pipelines, lifecycle logic, associations, integrations, reporting — works from Professional. If a scope is missing, there is usually a supported route through the UI or a private app, and that gets flagged before the work starts, not after.
Bring the thing that isn't working
A workflow that enrols nobody, a migration you do not trust, an integration that drops a field. Send the detail and you will get a real answer about whether it is fixable and what it takes.
Also worth reading: the ten automations worth building · the CRM migration guide