Should You Add Placeholder Actions Before Configuring a Workflow?
Building a workflow before every step is ready? See when placeholder actions help you draft the full flow first and what to finish before turning it on.

You have mapped out a lead follow-up flow on paper, but half the emails are not written and the assignment rules are still under discussion.
Should you build the whole sequence now with empty steps, or wait until every action is fully configured?
HubSpot documents a specific answer: certain workflow actions can be saved without setting their details.
You can add them as placeholders and fill them out later before turning the workflow on.
That documented behavior gives you a real option—but it also creates a failure mode.
A workflow full of unfilled placeholders is not ready to run, and the gap between “drafted” and “live” is where mistakes happen.
This article walks through when placeholders make sense, what must be configured before activation, and how to review the finished flow so nothing ships half-built.
What a placeholder action actually is
According to HubSpot’s workflow actions documentation, actions such as Create task and Send email can be saved without setting details.
You add your actions first as placeholders, then fill out your placeholder actions before turning the workflow on source: HubSpot Knowledge Base.
That wording matters.
The placeholder is a scaffold, not a functioning step.
An unfilled Send email or Create task action is a saved slot, not a finished step, and HubSpot requires filling these placeholders before turning the workflow on.
It reserves a position in the flow so you can see the whole structure at once.
HubSpot also notes that the actions available to you depend on your subscription, and that locked actions require an account upgrade to use source: HubSpot Knowledge Base.
So before you sketch a flow around a specific action, confirm it is actually available in your plan.
A placeholder built around an action you cannot unlock is a plan for a workflow you cannot run.
When placeholders are worth adding
Placeholders shine in three situations.
Each one is a judgment call, not a rule.
You want stakeholder sign-off on structure first
When a follow-up flow touches marketing, sales and possibly service, the argument is rarely about individual emails—it is about the shape of the process.
Who gets assigned, when the first touch happens, what happens if the lead does not respond.
Building the skeleton with placeholder actions lets reviewers react to the actual sequence instead of a slide deck.
If your reviewers will argue about branching logic, it can help to read up on the enrollment and trigger decisions first.
The choice of what starts the flow is a separate decision from what happens inside it, and our guide to choosing an automation flow trigger covers that question on its own.
You are coordinating content that is not ready
Follow-up flows usually depend on assets someone else owns: email copy under review, a task template sales has not approved, a survey still in draft.
Placeholders let you reserve each slot now and drop in the finished asset later, without restructuring the flow every time a dependency lands.
This is the use case HubSpot’s documentation most directly supports: add actions first as placeholders, then fill them out source: HubSpot Knowledge Base.
You are rebuilding or migrating an existing process
When you translate a manual process into automation, the first pass is often structural.
You know the sequence of steps but not yet the exact property values, delays or branch conditions.
Placeholder actions let you capture the process shape while the details are still being verified against how the team actually works.
When placeholders are the wrong tool
Placeholders are a drafting convenience, and drafting has limits.
If the flow is small and fully specified—two actions, clear conditions, copy already approved—placeholders add a step without adding value.
Configure it directly.
More importantly, placeholders do not solve design problems.
If you are unsure whether a step should exist, an empty action will not answer that.
Decisions about timing, exits and re-entry shape the flow more than any individual action.
Our articles on when a workflow should run on a schedule and setting the exit rule for contacts each cover a decision that is easier to settle before you commit to a structure.
Finally, placeholders do not substitute for testing.
A flow that looks complete because every slot is filled can still behave incorrectly once real records enroll.
Structure is not the same as correctness.
What must be configured before you turn a workflow on
HubSpot’s guidance is explicit on the sequence: fill out your placeholder actions before turning the workflow on source: HubSpot Knowledge Base.
In practice, that means walking the flow and confirming each step is genuinely finished, not merely present.
A practical pre-launch check:
- Every placeholder is filled. Open each action and confirm its details are set. An unfilled Send email or Create task action is not a working step.
- Enrollment triggers are final. Decide what qualifies a record for entry, including whether contacts can re-enter. The re-enrollment decision changes how the same flow behaves over time.
- Delays and dates are intentional. HubSpot supports delay actions that pause enrolled records until a specific calendar date, or until a date stored in a date or datetime property source: HubSpot Knowledge Base. Confirm each pause reflects the process you mean to run, not a default someone left in place.
- Property actions have compatible targets. If you use the Edit record action to set, copy or clear values, HubSpot notes that your source and target properties should have compatible property types source: HubSpot Knowledge Base. Verify the types match while you build.
- Permissions are in place. HubSpot requires Super Admin or Workflows permissions to create and edit workflows source: HubSpot Knowledge Base. If property access is restricted in your account, HubSpot documents that users with no access or View only permissions cannot add workflow actions that affect property values in new workflows, and existing workflows referencing restricted properties may display in view-only mode source: HubSpot Knowledge Base. Check who can actually finish and maintain the flow before launch day.
For a fuller pre-launch pass, our guide on reviewing a workflow before it goes live walks through the review step by step.
An illustrative build: lead follow-up with placeholders
Consider a common situation, described here as an illustration rather than a real customer result.
A marketing team is building a lead follow-up flow.
The structure is agreed: welcome email, short delay, task for the sales rep, then a branch on whether the task was completed.
The welcome email copy is still with legal, and the assignment rule is pending a sales leadership decision.
The builder adds four actions as placeholders in one sitting: Send email, a delay, Create task, and an if/then branch.
The visible skeleton goes to stakeholders, who approve the sequence and flag one change—the delay should sit before the task, not after.
Because the structure was built first, the fix is a drag-and-drop, not a rewrite.
Over the following days, the email copy is approved and dropped into the placeholder, and the assignment rule is confirmed and configured in the task action.
Only then does the builder run the pre-launch check above and turn the workflow on.
The builder's plan was to activate only after every placeholder was filled, so no record would enter an unfinished flow.
The contrast case: the same team configures each action fully as they build, one at a time.
When legal rewrites the email and sales changes the assignment rule, they edit live-configured actions repeatedly.
Each change is edited into an already-configured action, and the whole sequence may not get reviewed again as a unit.
Neither approach is universally better—the placeholder route paid off here because the dependencies were external and the structure needed sign-off.
Tradeoffs to weigh
The placeholder approach has real costs alongside its benefits.
- It defers work, not decisions. Every placeholder still needs a decision later. If those decisions stall, the draft sits unfinished and the process it represents stays manual.
- It can hide incompleteness. A flow where every slot is filled looks done. If someone turns it on without checking each action’s details, half-configured steps can run. The documented rule—fill placeholders before turning the workflow on source: HubSpot Knowledge Base—is only as good as the discipline behind it.
- It assumes the structure is stable. If the process itself is still contested, a skeleton may need repeated restructuring, which erodes the time saved.
If your flow depends heavily on record data being set correctly along the way, it is also worth deciding early whether steps should update related records.
Our article on whether a workflow should update associated company records covers that scoping question.
The choice of which object type to build the workflow on determines what your actions can even touch.
A suggested order of operations
Based on the documented behavior, a reasonable sequence looks like this:
- Confirm the actions you plan to use are available on your subscription, since locked actions require an upgrade source: HubSpot Knowledge Base.
- Settle the enrollment trigger and exit conditions before building, since they define the flow’s boundaries.
- Add the action skeleton with placeholders where details are pending.
- Review the structure with stakeholders and adjust the shape while changes are cheap.
- Fill every placeholder, checking property compatibility and delay logic as you go.
- Run a full pre-launch review, then turn the workflow on.
This order is a suggestion, not a requirement.
Teams with simple, fully specified flows may reasonably skip placeholders entirely and configure as they build.
The bottom line
Placeholder actions are a documented way to draft a workflow’s structure before its details exist source: HubSpot Knowledge Base.
They are most useful when structure needs sign-off, when content dependencies are pending, or when you are translating a manual process into automation for the first time.
They are least useful when the flow is small and fully specified, and they never remove the need to fill every action and review the whole flow before activation.
If you use them, treat the unfilled placeholder as a visible commitment: the workflow is not done until every one is configured and checked.
How Meshline can help. Connect automation, Organic Marketing (demand generation), and customer lifecycle management (Revenue Intelligence).
Bring topic planning, content publishing and performance feedback into the conversation about your workflow. Book a Meshline demo.