How do I set up role-based access so my junior marketers can't break the production flows?

Your instinct to create a separate project is exactly right. I run a similar setup for my team. We have a "Production" project and a "Marketing Sandbox" project. The permissions are granular enough to solve your problem - you can absolutely assign "Editor" in the Sandbox and "Viewer" in Production on a per-user basis. This is done in the workspace members settings, not at the project level, which is key.

However, a sandbox alone isn't a complete staging area. They can build flows, but true promotion to production requires a manual copy/paste by someone with editor rights there. We've instituted a peer-review rule: any flow moving from sandbox to production must be screenshotted and reviewed in our team channel first. It's a lightweight process that adds a crucial checkpoint.

For your segment list concern, pay close attention to data source permissions. You can grant access to a cloned "Sample Data" source in the sandbox while restricting the live database connection to senior roles only. This prevents those near-misses with live customer data.

You're right about the separate project being the core move, but I'd push back slightly on the manual copy/paste review. That process becomes a bottleneck and error prone fast.

I'd enforce the separation with automation. Our setup uses Terraform to manage the workspace and project roles. Juniors get the "Marketing Sandbox" editor role via a Terraform module, and that's it. The "Production" project isn't even visible to them in the UI because they aren't listed in its member config. No manual assignment to remember.

The real control point is CI/CD. We treat flows as code. A junior can export their sandbox flow as a JSON spec and submit a pull request. The pipeline validates it against our schema checks, then a senior engineer approves and merges. The pipeline applies it to production. They never get logins to the production project itself.

Your data source tip is critical though. That's where most of the "near miss" risk actually lives.

The CI/CD approach you describe is compelling for technical teams, but I'd question its practicality for a junior marketing team. The friction of requiring JSON exports and pull requests might stall their learning and experimentation entirely.

My follow-up question is about the schema validation in your pipeline. What are you checking for? In our HR software context, we'd look for specific data source permissions or PII handling rules. For a marketing team, I assume the validations would be different - perhaps ensuring no flow can be connected to a live customer database or production API endpoint?

The manual copy/paste with peer-review is a solid, human-friendly approach that scales well in a marketing team. It forces that extra moment of thought before anything goes live. We use a very similar method.

One practical tweak we've made is to have the reviewer actually perform the copy into production, not the junior marketer. This creates a single point of hand-off and eliminates any "oh, I just forgot to change one setting" errors during the transfer. It turns the review from a passive approval into an active gatekeeping step.

Your point about data source permissions is the real key, though. That's where the safety net is truly built.

The separate sandbox project is absolutely the way to go - you've nailed it. The granular "Editor in Sandbox, Viewer in Production" setup is exactly what those workspace member settings are for.

But I've seen a hundred teams stop there, and that's where you get a nasty cloud bill surprise six months later. Your juniors will start building sandbox flows that run every 5 minutes, or they'll connect their experiments to a live external API that charges per call. The sandbox protects your data, but not your wallet.

You need to couple that access control with strict budget alerts and, crucially, mock data sources. Create a duplicate "dummy" customer list in the sandbox that's safe to blast. Treat the sandbox's infrastructure budget like a real constraint they need to learn within. Otherwise, you're just moving the risk from your data to your CFO's patience.

Glad to hear Gemini's working out for you, and you've hit on a critical stage in scaling up the team. Your plan is spot-on.

Creating a dedicated sandbox project is the foundation. You can absolutely assign "Editor" there and "Viewer" on the production project per person in the workspace settings. That's the primary barrier.

But don't stop at permissions. The real-world advice I'd add is to also create dedicated, isolated data sources for that sandbox. Clone your customer list schema into a "Test Customers" list with dummy data. That way, even if they mistakenly connect a flow to "the list," it's hitting the safe one. It closes the last gap in your safety net.

Everyone's talking about projects and permissions, which is the obvious first step. Sure, set them up as editors in a sandbox.

But your core worry is about them connecting to the live customer list. That's the real failure point, and permissions alone won't fix it. Even with viewer access in production, they can still build a new flow in the sandbox and point it at the *production* data source if they can see it.

You need to lock down the data, not just the flows. Create a separate, isolated "test" segment in your CRM for the sandbox, and make sure the live one isn't even selectable as a connection from within that project. Otherwise, you're one misclick away from your near-miss becoming a real incident.

Your CI/CD approach is technically correct, but it's an overbuilt solution for this team. The overhead of JSON exports and PRs for junior marketers will kill their velocity and willingness to experiment. They're learning automation, not software engineering.

You've also missed the cost angle. Terraform-managed roles are clean, but if your schema validation doesn't enforce resource quotas or check for expensive API calls in those JSON specs, you're just automating potential budget overruns. The pipeline that applies to production needs hard cost guardrails.

Completely agree on the overhead being a deal-breaker. If you put that process in front of my marketing team, they'd just go back to doing things manually. The learning curve is steep enough.

But I think the cost guardrail point is the real gem here. A schema check for "does this flow contain our production customer database ID?" is easy. Validating for "will this workflow loop and hit an API 10,000 times an hour?" is much harder without running it. How do you even build that into a pre-merge check? You'd need to simulate execution, which brings you right back to needing a proper staging environment with real monitoring.