If you've ever opened a new AI feature in HubSpot, felt genuinely excited about what it could do, and then immediately closed the tab - high-five, I see you.

The hesitation is real. It's the feeling of being new to something that touches real data, real workflows, and real customer records, and not yet knowing the right order of operations.

Personally, I am just afraid I might accidentally email my whole contact list with something nobody asked for. Obviously, this has never happened.

The fear of breaking something is not irrational. It's the right default for anyone working with real customer data. My goal with this post is not to give you the armor to become fearless. I am writing this blog to help you, as a fellow builder, set yourself up for success – so you can try things safely, learn quickly, and avoid turning a small experiment into a very public mistake.

In this post, I’ll show you how to:

1. Set up a practice account that is completely isolated from your real account,
2. A framework for knowing what is safe to try anywhere, and
3. The approval moments HubSpot has already built in for you.
   

By the end, you'll have a test environment set up and one safe experiment done.

The best part: you do not need to be deeply technical to do any of this. You just need a safer order of operations.

Step 1: Create a practice account

Before you experiment with anything, you need a separate HubSpot account, one with no connection to your real one. Which one depends on where you're starting from:

• Developer test account: free, blank slate, up to 10 of them, includes a 90-day Enterprise trial. This is the recommended starting point for most builders.
• Standard sandbox account (Enterprise only): copies the structure of your production account: your real pipelines, properties, and workflows. Better if you want to test against something that already looks like your setup. Like a developer test account, marketing emails only go to users added to that account.

Pick your path. The rest of this step follows the developer test account, but the same logic applies either way.

Creating a Developer Test Account

A developer test account is a completely separate HubSpot account, it has no connection to your real one. Whatever happens in it stays in it. You can break things, delete things, run automations that do something unexpected, and your real data will never know.

Think of it as a flight simulator: it looks and works exactly like HubSpot, but you're not flying the real plane.

It's free. It takes under two minutes. And you can create up to 10 of them.

To create one:

1. In HubSpot, go to Development
2. In the left sidebar, go to Testing → Test Accounts
3. Click Create developer test account
4. Name it something obvious, like AI Experiment Sandbox
5. Click the box next to “Customize my test account”. You’ll notice that the default test account tier is set to Enterprise for all Hubs.
6. Click Create
   
   

Now you have a safe space to experiment. It is separate from production, it cannot sync data with other accounts, and even marketing emails can only be sent to users who are added to that test account.

Once you're inside, the blue banner at the top of every page tells you which account you're in. You can switch between your production account and your test account anytime from the account picker in the top right corner.

Step 2: Fill it with fake data

An empty account limits what you can test. AI is much easier to test when it has something to look at. So give yourself a tiny fake dataset.

The easiest way is to use HubSpot’s sample import files. HubSpot already provides example files for contacts, companies, deals, and tickets in CSV or XLSX format.

For a first experiment, keep it simple:

• 3 fake contacts
• 3 fake companies
• 1 fake deal

To import the file:

1. In your test account, go to Contacts
2. Click Import date from a file
3. Upload your CSV or spreadsheet
4. Map the columns to HubSpot properties
5. Finish the import

You can repeat the same steps for Companies and Deals. In this blog, I will focus solely on the Contacts.

If you want more control over your file first, HubSpot’s import setup guide spells out the rules: use .csv, .xlsx, or .xls, include a header row, and make each column match a HubSpot property.

One rule: avoid copying real customer records into a test account, even "just to see how it looks." It’s not because you can accidentally email them from here (you can't), it’s just good data hygiene. Fewer copies of real customer data floating around is always the right call.

Step 3: Know what's safe to try where

Not all AI actions carry the same risk. Start with something safe. Before you run anything, check the traffic light.

Green: try it now. Yellow: rehearse in test account first. Red: this is not a casual click around moment, plan it like a project.

Before you ask, this is not a metaphor I invented. It is the most useful mental model for not having a bad Tuesday.

Most day-to-day work, you’ll find, is either green or yellow.

🟢 Start with a green-light AI action: safe to try in production, right now

These are assistive by default. AI proposes. You approve. Nothing goes anywhere without a deliberate action from you.

Do not make your first experiment “rewrite my lifecycle stages” or “update 4,000 records.”

Examples of green use-cases:

• Asking Breeze Assistant to summarize or explain a record, draft an email, or suggest a next step
• Drafting content that still needs your review
• Asking AI to analyze a pipeline or report – reading data, not changing it
• Viewing AI-generated contact insights on a record, lists, or pipeline patterns
• Exploring what might be possible
  
  

A good first move is to ask Breeze Assistant to help you understand the fake data you just loaded.

Try a prompt like this:

• “Summarize these contacts and tell me what stands out.”
• “What would be a useful next step for this sample pipeline?”
• “What signals would help me identify stale leads before I build automation?”
  
  

This is a much better first experiment than asking AI to change anything.

Why? Because you’re learning how the assistant thinks, what context it uses, and whether the output is useful before you hand it anything with consequences.

🟡 Yellow: test in your test account first, then graduate to production

These make real changes that may affect many records or be hard to reverse.

• Building and turning on AI-assisted workflows that auto-enroll contacts
• Using AI to bulk-update contact properties (lifecycle stage, owner, lead status)
• Creating lists that will feed automation
• Drafting email sequences you might eventually send

Tip: Tell your agent: "Do not make any actual changes, anticipate what side effects could occur if the changes were made." While not a 100% surefire way to prevent an agent from accidentally breaking something, this can be a valuable tool to help you move quickly and more safely.

🔴 Red: plan it, don't just experiment

High scope, hard to reverse. Not "don't do it", but "slow down and get a second pair of eyes."

• AI-assisted bulk import or update of thousands of records
• Enabling automation across your entire contact database
• Sending emails at scale before testing delivery end to end
• Using AI to delete or archive records
• Anything that could affect customers, revenue, or shared account settings

Tip: Use your agent's planning mode or directly ask it to help you create the plan long before ever having it actually implement it. Review the plan thoroughly to ensure it actually is what you want before having it execute. Consider having the agent also list the possible side-effects of the change to help you understand the level of risk.

Now this is where a standard sandbox account also earns its place. If you're on Enterprise and the change is significant enough to plan like a project, it's worth testing against something that looks like your production account.

Step 4: Have the agent create drafts rather than go right to publishing

Now let’s do something real.

Say you want to build a workflow that creates a follow-up task for every contact with an email address.

Do not start in production. Do not start with your whole database.

I know "let's see what happens" is a compelling strategy. I have been that person. I am asking you to be different.

In your test account, build one tiny workflow in draft mode:

Open Breeze Assistant and paste this prompt:

“Create a contact-based workflow.

• Set an enrollment trigger like: Contact has an email address.

• Add one action: Create a task with the subject ‘Test workflow task’.
• Stop there. Leave it in draft.”
  
  

Remember, Breeze Assistant proposes, it doesn't act. When it drafts an email, you still click Send. When it summarizes a contact, nothing on the record changes. When it suggests a next step, you choose whether to take it.

And here’s the important part: the workflow exists, but nothing is happening yet.

Even in production, HubSpot has built-in pause-and-review points. These are approval moments, i.e. places where the platform stops and says "here's what I've prepared, what do you want to do with it?" Nothing goes live until you decide.

Every workflow you create is inactive by default. You can build the full logic, preview which contacts would enroll, and review the whole setup before anything happens. The approval moment is the Turn on button and that click is always your decision.

HubSpot is giving you a chance to review the logic before you turn anything on. Use it.

Step 5: Test one record before you touch many

Before turning on any workflow against your full list, manually enroll one test contact and watch what happens step by step.

Pick one contact in your test account. Make sure they match the rules. Then manually enroll just that one record and watch what happens.

Did the task show up on the contact record?

Did anything weird happen?

This habit will save you from a shocking amount of cleanup later.

One rule that has nothing to do with HubSpot features

One quick warning: your setup can be safe and still become unsafe if you handle credentials badly.

If you use Service Keys, Developer API keys, or Personal Access Keys, or really any API keys or authentication information at all, treat them like passwords. Do not paste them into docs. Never give them to your AI tools. Do not leave them visible on a screenshare. Do not use the same access setup for your practice account and your production account unless you have to. Anyone with those credentials can take the same level of destructive actions that you can. In programming these are commonly referred to as secrets.

The AI experiment is only as safe as the setup around it.

I don't say this because I think you'll be careless. I say this because it's surprisingly easy to be careful about the big things and sloppy about the boring ones. Credentials are the boring thing.

If you are connecting AI tools to HubSpot via a private app, your access token is a master key to your account. Anyone who has it can read and write data in your account. It does not expire on its own.

Rules of thumb:

1. Never share your screen while a token is visible: close the terminal, if you’re using one, and your .env file before you share your screen. If you already accidentally shared your credential - rotate it - which means deleting the old key and creating a new one. It might be a minor inconvenience now but would save you a lot of trouble.
   
   
2. Don't store secrets in your code: instead store them in a .env file that is excluded from any repository, the tool they are used for:
• Personal Access Keys are managed for you by the HubSpot CLI
• There is a secrets command in the HubSpot CLI if your serverless functions require secrets.
• GitHub has a secrets management tool built into your repository settings.
• And if you're using custom code actions in HubSpot workflows, HubSpot has built-in secret management for those too.

Just don't paste them directly into a script or give them to anyone including your agent.

That’s it. That’s your first safe experiment!

You don’t need to "go big" to get started with AI in HubSpot. You need a safe place to learn, a small experiment to run, and the patience to check what's happening before you scale it.

(And maybe a test account named something more creative than "AI Experiment Sandbox.")