Customer.io Split Building a Campaign From Sending It. Here's the Permission Set to Hand a Client

On 6 June 1962, President Kennedy signed National Security Action Memorandum 160. Its subject line, held in the John F. Kennedy Library and published by the National Security Archive at George Washington University, was "Permissive Links for Nuclear Weapons in NATO". The memorandum committed the United States "to procure appropriate devices for all nuclear weapons, now dispersed and to be dispersed to NATO commands, for both non-U.S. and U.S. forces".

The device came from a memorandum Kennedy's science adviser Jerome Wiesner had sent eight days earlier. Wiesner proposed an "electro-mechanical lock which would have to receive a preset numerical code in order to make the weapon operable". Steven Bellovin, then at Columbia University, described the result to a USENIX audience on 20 April 2006 as "the cryptographic combination lock on nuclear weapons". The military resisted at first, worried about reliability. What changed their minds was the thing the lock made possible: you could put a weapon somewhere useful without the person guarding it being the person who decided to use it.

That is the whole idea. Holding the thing and being allowed to use the thing became two separate permissions. Customer.io took until 10 July 2026 to apply the same reasoning to your marketing automations.

TL;DR:

• Until 10 July 2026, anyone who could build a Customer.io automation could also start it. The release note is blunt: "Previously if you could create an automation or broadcast, you could also activate that automation or send that broadcast." Execute is now a separate permission, and for most teams the people who build should not be the people who send.
• Custom roles you created before 10 July 2026 kept their old behaviour unless you edited them. If you have not touched your roles since, your builders can still send. That is the audit to run this week.
• Custom roles are Premium and Enterprise only. On Essentials you get three standard roles and no Execute split, so the answer there is process, not permissions.
• Permissions accumulate left to right, and Execute sits at the right-hand end of the row. On the documented reading, that means Execute comes with Delete attached, so an approve-only role is not something you can promise without testing it. Either way the split gets made by taking Execute away from builders, not by handing it to an approver.
• Two limits nobody advertises. An App API key "gives you access to the complete API, regardless of permissions set on your custom role", so Execute governs the app and not the account. And Customer.io's documented workspace audit-log activity list covers automations, actions and templates—there is no "message sent" entry. You can prove who changed a send. Who pressed it is a different exercise.
• Two days after Execute, on 12 July 2026, guest access shipped: one login across every account you are a guest of, permissions set per account. For agencies, that retires the shared-login and [email protected] era for good.

What actually changed on 10 July 2026

Customer.io added two permissions to the custom-role builder and left everything else alone.

The first is Execute. For automations it means "Start, schedule, and stop automations". For broadcasts and one-time sends it means "Send, schedule, and stop broadcasts and one-time sends. This includes triggering API-triggered broadcasts". For transactional messages it means "Send transactional messages". The release note puts it in one line: "To activate your workflows and send messages, you need the Execute permission for the workflow."

The second is Send, attached to Deliveries & drafts, and it covers the retry cases: "Send drafts, retry attempted messages, or resend deliveries." It does not work alone. The same release note is specific: "To resend deliveries, retry attempted messages, or refire webhooks, you need the Send permission for Deliveries & Drafts and Edit permission for the relevant workflow." Two permissions, two different parts of the table, both required for one action.

One naming trap. Five days after the Execute release, on 15 July 2026, Customer.io renamed six navigation labels—Campaigns became Automations, People became Profiles, and Deliveries & drafts became Message activity. The permission kept the old name. So you will look for a Message activity permission, fail to find one, and need to know that it is filed under Deliveries & drafts. We wrote about the wider rename and which of your playbooks it breaks when it landed; this is one more artefact of it.

Seven permission tiers exist, not six

The one most write-ups miss is Publish, which belongs to Design Studio and controls whether someone can push a design change into a message that is already wired into a live automation. Everything here is from the Create & assign custom roles documentation, updated 1 September 2026.

Tier	What it grants	Where it appears
View	Read access. Required on every custom role.	Every feature
Edit	Change an existing thing. For automations this includes creating any message type, sending test messages and manually ending a profile's journey.	Most features
Create	Add or duplicate. For automations it also covers archiving.	Most features
Delete	Remove.	Most features
Execute	"Start, schedule, and stop automations"; send and schedule broadcasts, including triggering API-triggered ones; send transactional messages.	Automations, Broadcasts & One-time sends, Transactional Messages
Send	"Send drafts, retry attempted messages, or resend deliveries." Needs Edit on the relevant workflow too.	Deliveries & drafts
Publish	"Push message and design updates to messages connected to workflows like automations."	Content Library & Design Studio

Two features behave differently and both matter in practice. Anonymous In-App Messages have no Execute tier at all—scheduling them, starting and stopping included, is folded into Create. And transactional messages carry a note that reframes the whole permission: "To send a transactional message, you need an App API key." Which brings us to the rule that governs the rest of the table.

Permissions accumulate, so role design runs downhill

The documentation states the constraint twice, in two sentences worth quoting exactly:

Custom roles must minimally have all view permissions.

Permissions accumulate; to grant a permission on the right, you need all the permissions on the left. For instance, to delete automations, you must also be able to view, edit, and create them.

Most people read that as a small implementation detail. It is the single most important thing on the page, because of where Execute sits.

The Automations row runs View, Edit, Create, Delete, Execute, in that order. Apply the rule literally and Execute—the rightmost tier—requires all four permissions to its left. A role that can start an automation can also delete one. Which means the thing most teams reach for first, an approver who can press send and touch nothing else, is not a role you can build. Check it in your own account before you promise a client otherwise, because the checkboxes are what govern; but the documented rule points one way only.

So the split runs in the other direction. You do not add sending to a builder. You start from a role that can do everything and remove Execute from the people who build, leaving a small group who kept it. That is a subtractive exercise. It is also why Customer.io's own Quick Setup option—start from a standard role, then untick—beats assembling a role from an empty grid.

The audit to run this week

Here is the sentence in the release note that should worry you more than any of the others:

Custom roles created before this release have the same permissions as before—unless you update the role.

Nothing was taken away and nothing was tightened. Custom roles themselves only arrived on 9 December 2025, so the window is narrow and specific: any custom role built between then and 10 July 2026. A role you set up in March 2026 to let a contractor draft emails still lets that contractor start an automation. On 9 July 2026 those were the same capability, and the migration preserved behaviour rather than intent. The new permission exists in your account; it is switched on for everyone who previously had the equivalent.

Four steps, in order:

1. Go to Account Settings > Roles and open each custom role. The Roles page lists affected people under Users, so you can see who a change will hit before you make it.
2. For every role, ask one question: should a person with this role be able to start a live automation or send a broadcast? If the answer is no, remove Execute.
3. Export your team list. Account Settings > Team Members has an Export to CSV button built for exactly this—Customer.io describes it as being there "to help you audit access to your account". You get every team member and their access to every workspace in one file.
4. Tell people before you save. Permission changes "take effect immediately", and Customer.io is direct about the consequence: reduce a role that is assigned to someone currently logged in and "they may lose their work". It is also direct about the notification: "We do not notify team members if their permissions changed."

That fourth step is not politeness. A senior marketer who loses Execute silently, mid-launch, on a Friday afternoon, will file a support ticket and lose an hour before anyone connects it to your tidy-up.

Six roles cover most SMB and agency setups

This is our recommendation, not Customer.io's. Six roles that cover most SMB and agency setups, against the seven decisions that actually change what a person can do. "Highest tier" encodes the accumulation rule: granting the tier named also grants everything to its left.

Role	Automations	Broadcasts & one-time sends	Transactional	Deliveries & drafts	Design Studio	Workspace settings	Manage API credentials
Junior marketer	Edit	View	View	View	Create	View	No
Senior marketer / lifecycle lead	Execute	Edit	View	Send	Publish	View	No
Agency builder	Create	Create	View	View	Publish	View	No
Agency lead	Execute	Execute	View	Send	Publish	Edit	No
Developer / marketing engineer	View	View	Execute	View	View	Edit	Yes
Client-side approver	Execute	Execute	View	Send	View	View	No
Workspace admin (standard role)	Full	Full	Full	Full	Full	Full	Granted separately

Four decisions in that grid are worth defending.

The agency builder tops out at Create, deliberately. An agency that builds your programme should be able to create, duplicate, edit and archive automations and never start one. It is the role that makes an agency relationship legible to a client's security review. It is also the role most agencies have never been able to offer, because until 10 July 2026 it did not exist. We migrated AIRE Health off an internal custom email system onto Customer.io and rebuilt their campaigns, taking conversion from 7.0% to 17.8%. That handover conversation would have been shorter with this role available.

Developers get Execute on transactional and nothing else. Transactional sends are triggered by application code, not by a person clicking a button, so the person maintaining that code needs the permission and does not need marketing sends. They do need Manage API credentials, which is an account-level permission granted on the team member rather than in the role.

The client-side approver keeps Delete, on the documented reading of the accumulation rule. If your client wants a named person who can approve and launch, expect that person to be able to delete the automation they just launched. Test it, then say so out loud in the kickoff call rather than discovering it in month three.

Nobody except an Account Admin gets Workspace settings Edit casually. That permission covers message limits, automatic merge settings and time zone settings—three ways to change what your whole programme does without touching a single automation. The agency lead gets it because message limits are usually their call. The junior marketer does not.

Why your team suddenly cannot edit a live automation

There is a second-order effect of the Execute release that catches teams unprepared, and it is buried in the Edit description rather than announced anywhere:

To edit live automations, you also need the Execute permission for automations.

The same note appears for broadcasts: editing a live API-triggered broadcast needs Execute as well. So the moment you strip Execute from your builders to stop them sending, you also stop them editing anything that is already running. A build-only role can build. It cannot fix.

For a lot of programmes that is a feature—the change goes through the person who can also restart the thing, which is roughly what a deployment review is for. But the rules about what happens to people in-flight when you edit a live campaign become a smaller group's problem than they used to be. Your build-only role then needs a documented route for "this live automation has a broken link". Usually that route is: builder duplicates, fixes the copy, hands it to whoever holds Execute. Slower. Also correct.

The other side of the same coin is Design Studio's Publish permission. A designer can hold Create on Design Studio, build and edit templates all day, and still not be able to push a change into a message attached to a running automation. If you are already running a review step before send—Design Studio's readiness score and review panel make a decent gate—Publish is where that gate becomes a permission rather than a habit.

Guest access: the other half of the problem

Two days after the Execute release, on 12 July 2026, Customer.io shipped guest access. Where custom roles control what a person can do inside an account, guest access controls which accounts a person can reach at all. Together they are the whole of agency governance.

The release note leads with the thing every agency has been working around for years: "One login for all your accounts… No more inventing a new email address and password for every account." Customer.io's own documentation names the workaround it replaces: [email protected]. It existed because every Customer.io login is tied to a unique email address, and an email address can only belong to one account.

Here is what decides between the two models.

	Guest access	A separate login per account
Logins to manage	One	One per account
Email addresses needed	One	One per account, usually aliased
Who sets your permissions	Each account's admin, per account	Each account's admin, per account
Role in your own account	Does not carry over	Not applicable
Attribution of your actions	To you, in that account	To the alias
Removal	Account admin deletes you; your login and other accounts untouched	Account admin deletes the alias
Accounts reachable	Every account that invited you	Every account you hold a login for
Session behaviour	Switch without logging out	Logging out logs you out of all of them

Three details from the Access multiple accounts documentation that change how you set this up.

Permissions do not travel. "You're granted permissions by whomever grants you guest access… you can have different permissions in every account you're a guest of—your role in your main account doesn't carry over." An agency lead who holds Execute in three client accounts and build-only in a fourth is a supported configuration, not a workaround.

A guest must already have their own account. Customer.io is explicit: "Anyone you invite as a guest must already have their own Customer.io account—if they don't, add them as a regular team member instead." So the agency needs its own Customer.io account before this works. Partner accounts do, by definition.

You cannot copy a guest's permissions. The invite flow has a Match permissions from another member option that copies an existing person's access onto a new invite. It comes with a limit: "You can only match a native team member's access, not a guest team member's permissions." Set up your first agency guest carefully, because you will be doing it by hand every time.

For partners specifically, Account Settings > Partner Settings lets an agency create client accounts directly. Customer.io notes the consequence: "You're automatically added to each account you create as an Account Admin, and the client's owner receives an email invitation to set up their login." That is a sensible default and a slightly awkward one—the agency starts with more access than the client. Downgrade yourself once the client's own admin is in place.

Migrating off aliases is straightforward. If your logins use Google and share a Google identity, Personal Settings has a Merge Google logins option. Otherwise, log into each account, find the aliased team member on the Team Members page, and select Change to guest; it invites your real address and removes the old login when you accept. One warning from the docs: a merge that would remove the only Account Admin from an account is blocked, so add a second admin first.

Worth saying plainly, because it is the objection that never survives contact with the facts: seats are free. "Customer.io does not charge for team members," the team members documentation says, and the cap is 300 across all workspaces. The pricing page calls user seats unlimited on all three plans, so the two pages disagree on the ceiling and agree on the price. There has never been a cost reason to share a login.

What Execute does not cover

Two limits, both documented, neither mentioned in any announcement. If you are building a permission model that someone will rely on, you need both.

An App API key walks straight past your custom role

From the create-roles page, in the section on API credentials:

Each key gives you access to the complete API, regardless of permissions set on your custom role. For instance, if you have the "Manage API credentials" permission, then you can create profiles and send events even if you don't have the Edit or Create permissions for Profiles.

Read that against the Broadcasts row, where Execute "includes triggering API-triggered broadcasts", and the shape of the problem is clear. Execute controls who can trigger an API-triggered broadcast from the app. A person with an App API key can trigger it with a curl command, and the permission model has no opinion about that at all. The same goes for transactional sends, which need an App API key by design.

So Execute is a control on people using the interface. It is not a send lock on the account. The account-level Manage API credentials permission is the one that matters for the API surface, and it belongs to a much shorter list of people than Execute does. It is also why the role-tiered approach we set out for Customer.io's MCP server matters. The MCP documentation is clear that connections "respect that user's role and permissions—your AI tool can only do things you can do", and that "you cannot grant the MCP server greater access permissions than you personally have in Customer.io—but you can grant it less". So Execute is what stops an agent starting a campaign. MCP adds a second gate on top: sending needs the write:live scope, and an account admin has to unlock that with an Allow MCP to edit live data setting. A key sitting in an environment variable is governed by none of it. The same logic applies to the guardrails worth locking before you let the AI Agent build.

The audit log records changes, not sends

Customer.io's audit logs are genuinely good. There are two: an account log covering "team member session data, changes in permissions, and deletion of API keys", and a workspace log covering changes team members made to the workspace. Both filter by date range, team member, IP address and event type. Both offer a Show diff view of "how the event changed your account or workspace data", red for removed and green for added.

What the documented workspace activity list contains is Automation, Automation Action, Template, Segment, Import, Export, Domain, Tag and about two dozen more of the same kind—configuration and content. What it does not contain is an activity for a message being sent. The account log will show you every permission change and every role edit, which is exactly what you want when you are auditing a role migration. Neither log gives you a line that says "Priya started this automation at 14:32".

That is a real gap for the question a client's security review actually asks. The honest answer is that you reconstruct it: the automation's audit entry shows the change and its diff, Message activity shows what went out, and the two together tell you the story. If your compliance requirement is a single attributable send event, plan for the reconstruction rather than assuming the log has it.

Two more things about audit logs, both worth knowing before you promise anything. Retention is plan-dependent. On Essentials you get "the past 30 days". On Premium or Enterprise you "can view and filter for data over any time period, but you can only export up the past year of activities". And the docs and the pricing page disagree. The pricing comparison table lists "Audit logging & data governance" as an Enterprise line, "Available by Consultation"; the docs describe audit logs working on every plan with different retention. Check what your own account shows rather than either page.

One thing the logs do handle well, and recently: AI activity is attributed to a person. Customer.io "attributes activities in the system to both the AI agent and the person who tasked an agent with an action". Entries read AI Agent (on behalf of [email protected]), and the Slack agent is attributed separately as Slack Agent. So an agent acting under a role that lacks Execute leaves a named trail either way.

When not to split build from send

Three situations where a single role is the right answer.

You are on Essentials or Builder. Custom roles are Premium and Enterprise only—the create-roles page carries both badges and says so in its first paragraph, and the plan features page is where Builder appears at all. Below that you have three standard roles: Workspace Admin, Author and Viewer. There is no documented build-but-do-not-send standard role, so the control does not exist and pretending otherwise wastes a week. The answer is a written rule, a launch checklist and a second pair of eyes. If you are weighing the upgrade, what the Builder plan is and is not is the honest version of that decision.

You are a team of one or two. A permission boundary between two people who sit next to each other adds a step and removes nothing. Split when there is a third person, or when the person building is not the person accountable for the send.

Your sends are almost all transactional. Execute on transactional messages is a developer permission and the trigger is application code. If your programme is receipts, password resets and shipping notifications, the useful control is your deploy process, not your Customer.io role.

There is a fourth case that looks like an exception and is not. Teams often argue that separating build from send will slow launches down. It will, by roughly the length of one message. What it removes is the class of incident where a test broadcast goes to a live segment, and that is not a slow-launch problem, it is a who-was-on-the-list problem with a much longer tail.

Where to start

1. Check your plan. Premium or Enterprise, or stop here and write a process instead.
2. Open every custom role in Account Settings > Roles and remove Execute from anyone who should not be starting automations or sending broadcasts. Tell them first.
3. Decide who holds Execute. Write the names down. Two or three people for an SMB; one on the client side and one at the agency is a workable pair.
4. Move your agency onto guest access and delete the aliased login. Set the agency's role to build-only unless they are running your launches.
5. Count your App API keys and work out who can use them. That list, not your roles page, is who can actually send.
6. Export the team list to CSV and put it in the folder your next security review will pull from.

We run this configuration for clients as their Customer.io team, and the build-only agency role has made the client-side security conversation shorter every time. Want a second pair of eyes on your role matrix? Tell us how your account is set up. Or read what a Customer.io agency engagement looks like, and how it differs from a fractional lifecycle manager inside your team.

Frequently asked questions

What is the Execute permission in Customer.io?

Execute is the custom-role permission that controls whether someone can activate a workflow. For automations it means "Start, schedule, and stop automations". For broadcasts and one-time sends it means "Send, schedule, and stop broadcasts and one-time sends", including triggering API-triggered broadcasts. For transactional messages it means "Send transactional messages". It shipped on 10 July 2026 and is available on Premium and Enterprise plans only.

Can I let someone build campaigns but not send them?

Yes, since 10 July 2026, if you are on a Premium or Enterprise plan. Create a custom role with View, Edit and Create on Automations and leave Execute unticked. That person can build, duplicate, edit and archive automations and send test messages, but cannot start one. Be aware that they also lose the ability to edit automations that are already live, because the documentation states that editing a live automation requires the Execute permission too.

Do custom roles require a Premium plan?

Yes. Customer.io's documentation says "If you're on a Premium or Enterprise plan, you can create roles with custom permission sets. Otherwise, you'll assign one of our standard roles with predefined permissions." The three standard roles are Workspace Admin, Author and Viewer. Premium pricing starts at $1,000 per month billed yearly.

Did my existing custom roles change on 10 July 2026?

No, and that is the problem. The release note says "Custom roles created before this release have the same permissions as before—unless you update the role." Any role that could previously create an automation can still activate one. You have to open each role and remove Execute yourself.

What is the difference between Execute and Send in Customer.io?

Execute activates a workflow: it starts, schedules and stops automations, broadcasts and one-time sends. Send belongs to Deliveries & drafts and covers the retry cases—sending drafts, retrying attempted messages and resending deliveries. Send does not work on its own; the documentation says you also need Edit permission for the relevant workflow, and refiring a webhook needs the same pair.

Can I create a role that can send but not edit anything?

Probably not. Customer.io's rule is that "permissions accumulate; to grant a permission on the right, you need all the permissions on the left". Execute sits at the right-hand end of the Automations row, after View, Edit, Create and Delete. Read literally, that means anyone with Execute also has Delete. An approve-only role is not something you can promise a client without testing it in your own account first.

Why can my team no longer edit a live automation?

Because you removed Execute. The Edit permission description carries a note that is easy to miss: "To edit live automations, you also need the Execute permission for automations." The same applies to live API-triggered broadcasts. A build-only role can build new automations but cannot change one that is already running, so give it a documented route to whoever holds Execute.

How do I give an agency access to Customer.io without sharing a login?

Invite them as a guest. Go to Account Settings > Team Members, click Invite a guest, and enter the email address they use on their own Customer.io account. Set their account-level and workspace-level roles the same way you would for any team member. They accept by email, your account appears in their account switcher, and they sign in with their own login. Invitations expire after seven days, and non-admins need access to at least one workspace.

Are guest actions recorded in the audit log?

Guest actions are attributed to the guest. Customer.io's documentation says "Everything a guest does in your account is attributed to them, and permission changes are recorded in your audit log—the same as any other team member." The release note phrases it more broadly, as "everything they do is recorded in that account's audit log". Either way, what the audit log records is changes and permission events, not individual message sends.

Can a guest have different permissions in different accounts?

Yes. "You can have different permissions in every account you're a guest of—your role in your main account doesn't carry over." An agency can hold build-only access in one client account and full Execute rights in another, from the same login.

What is Partner Settings in Customer.io?

Partner Settings is a page available to accounts flagged as partners—agencies and consultancies that manage client accounts. From it you can create client accounts directly and see all of them in one place. You are automatically added to each account you create as an Account Admin, and the client's owner gets an email invitation to set up their own login. Becoming a partner goes through your account manager.

Can someone send messages through the API without the Execute permission?

Yes, and this is the limit worth knowing. The documentation says "Each key gives you access to the complete API, regardless of permissions set on your custom role." Execute controls who can trigger sends from the Customer.io interface. Anyone with a working App API key can call the API directly, and transactional messages need an App API key by design. The account-level "Manage API credentials" permission is the control that matters there.

Can I audit who sent a broadcast in Customer.io?

Not from a single log entry. The documented workspace audit-log activity types cover automations, automation actions, templates, segments, imports and exports—configuration and content changes, each with a diff view. There is no "message sent" activity. To answer the question you combine the automation's audit entry with Message activity, which shows what went out. Plan for that reconstruction if a compliance requirement depends on it.

What permissions does a developer need in Customer.io?

For transactional sending: Execute on Transactional Messages, plus the account-level "Manage API credentials" permission, which is granted on the team member rather than inside the role. Complete API-key access takes both that permission and Edit on Integrations, which is what lets them view and copy Pipelines keys. They rarely need Execute on Automations or Broadcasts, because application code triggers their sends. Note that any API key they hold bypasses the role's other restrictions.

How do I stop a live automation if I do not have Execute?

You cannot—stopping is part of Execute, alongside starting and scheduling. This is the argument for keeping at least two people with Execute in every workspace, and for making sure at least one of them is reachable outside your own working hours. If nobody with Execute is available, an Account Admin always has full permissions in every workspace.

Sources

• Custom roles: determine who can send messages—Customer.io release notes, 10 July 2026
• Manage all your accounts with a single login—Customer.io release notes, 12 July 2026
• New names for familiar parts of Customer.io—Customer.io release notes, 15 July 2026
• Create & assign custom roles—Customer.io Docs, updated 1 September 2026
• Assign standard roles—Customer.io Docs, updated 1 September 2026
• How to add team members to your account—Customer.io Docs, updated 1 September 2026
• Access multiple accounts—Customer.io Docs, updated 1 September 2026
• Audit logs—Customer.io Docs, updated 1 September 2026
• Get started with the Customer.io MCP server—Customer.io Docs, updated 1 September 2026
• Manage access to your workspace with custom roles—Customer.io release notes, 9 December 2025
• Plan features—Customer.io Docs, updated 2 September 2026
• Pricing + Plans—Customer.io
• National Security Action Memorandum 160, "Permissive Links for Nuclear Weapons in NATO", 6 June 1962—National Security Archive, George Washington University
• PAL: Permissive Action Links, Nuclear Weapons, and the Prehistory of Public Key Cryptography—Steven M. Bellovin, Columbia University, 20 April 2006