Workspaces
Set up Live, child, and Sandbox workspaces; understand shared billing, roles, testing, and day-to-day workspace management.
What is a workspace?
Use workspaces to separate environments, teams, brands, customers, or applications. Switching workspace changes the data and credentials you work with. It does not automatically grant access to another workspace, even when both workspaces share billing.
When you create a Simply Send account, you start with one personal Live workspace. Use it for production setup, or create additional Live children and Sandbox workspaces as your needs grow.
Live workspace
A production workspace. It sends real email after normal domain verification and uses its own credentials, resources, team, and email balance.
Sandbox workspace
A test-only child workspace. It simulates sending to Simply Send test addresses and never delivers externally. See Sandbox Testing for the complete test guide.
Create a workspace
- Open Account, then open the Workspaces section.
- Select New Workspace.
- Choose Live for production use or Sandbox for safe simulation.
- For a child workspace, select an eligible parent. Leave the parent empty only when creating a top-level Live workspace.
- Enter a workspace name and workspace contact email, then create the workspace. The contact email can be the same as the user creating the workspace. The creator becomes the child workspace Owner.
The create control is shown to users with team:write rights. The service rechecks permissions and quota when the workspace is created, so a stale screen cannot bypass the rules.
Parent and child workspaces
A parent is a top-level Live workspace that owns the billing relationship. A child is a separate workspace linked to that parent. Children share the parent's subscription and plan limits, but keep separate resources, credentials, membership, analytics, and email balances.
To add a child: the chosen parent must be a top-level billing-owner Live workspace, the user must have team:write there, and the parent must have available child-workspace capacity.
For a Sandbox child: the parent must also have an active paid subscription. Sandboxes cannot be top-level workspaces and cannot be parents themselves.
One level only: a child cannot create another child.
Manage a workspace
Open Account → Workspaces, then choose the workspace you want to manage. The available tabs depend on your role and permissions.
Members
Open Members and click Add Member. Enter the person's email, choose a role, and send the invite. You can also review, resend, cancel, or remove invitations and members here.
Roles
Open Roles and click Create Role. Give the role a name, choose at least one permission, and save it. Use custom roles when the built-in roles give too much or too little access.
Branding
Open Branding to change the workspace name or its contact email. The contact email belongs to the workspace and can be the same as the person who created it.
Test Data Allowlist
This Live-workspace tab protects real email-event data. Add a test recipient email or a verified sender domain. Team members who can view Email Events can then investigate matching test events without broad recipient, subject, or PII access. All other event data stays protected.
Subscription, limits, and credits
Subscription: children inherit the parent's billing subscription. A Sandbox requires an active paid parent; it does not have a separate subscription fee.
Workspace capacity: plans set the number of top-level and child workspaces that can be created. The parent's child-workspace limit is checked whenever a child is created.
Credits: each workspace maintains its own email balance. Sending from a child, including a Sandbox, consumes that child's balance by recipient at the applicable Transactional or Marketing rate. A billing owner with billing:manage can transfer available credits to a child in the same billing account.
Cost of simulated sends: sandbox sending is not an external delivery charge, but it is not free traffic. It consumes the sandbox workspace's email credits at the rate for the send type. Check your plan and credit balance for current pricing and availability.
Roles
Roles are assigned per workspace. A role on a parent does not automatically apply to a child. Owners can assign built-in roles and suitable custom roles; non-owners can assign only permissions they already hold.
| Role | What it is for |
|---|---|
| Owner | Full workspace access, including billing, deletion, and assigning the Owner role. |
| Admin | Manages members, roles, settings, domains, credentials, and workspace resources. Admin includes team:write. |
| Editor | Drafts templates, campaigns, workflows, and compliance-template changes. |
| Marketer | Manages audiences and executes approved marketing campaigns and workflows. |
| Content Approver | Reviews and approves campaigns, templates, and workflows. |
| Developer | Views technical setup, credentials, integrations, analytics, and delivery diagnostics. |
| Analytics Viewer | Views aggregate analytics only. |
| QA Event Viewer | Views redacted email-event data for testing and quality assurance. |
| Deliverability Manager | Investigates delivery data and manages suppressions. |
team:write, so an Admin can create an eligible child from a parent. Only an Owner can manage billing, delete a workspace, or assign the Owner role.Permissions
Permissions apply only to the selected workspace and an active membership. A write permission includes read access to the same resource; delete, execute, approve, send, and other actions must be granted separately. Effective access combines the role with unexpired additional grants, minus explicit denials. Non-owners cannot grant permissions they do not hold; Owner assignment and final-owner protections still apply.
These are workspace-member permissions, not a promise that every keyword has a public API endpoint. api_key permissions also satisfy the matching action on marketing_api_key, transactional_api_key, and web_api_key. Web Setup API keys have a restricted service-principal scope list and cannot inherit all user permissions. Supabase configuration additionally requires integration:write, smtp:write, and domain:read. Importing built-in templates requires factory_email_template:read and email_template:write.
Workspace and team
| Keyword | What it allows |
|---|---|
workspace:read | View workspace details. |
workspace:write | Update workspace resources where supported. |
workspace:delete | Delete the workspace; Owner-only safeguards also apply. |
team:read | View members, invitations, and workspace-wide limits. |
team:write | Invite or update members, resend invitations, grant additional access, manage branding, and create eligible child workspaces. |
team:delete | Remove members, cancel invitations, or revoke additional grants. |
role:read | View available roles. |
role:write | Create or update custom roles. |
role:delete | Delete custom roles. Built-in roles cannot be edited or deleted. |
settings:read | View workspace settings. |
settings:write | Change workspace settings, including supported security settings and the workspace name. |
workspace_profile:read | View workspace company/profile details. |
workspace_profile:write | Update workspace company/profile details. |
analytics_pii_policy:read | View the email-event test-data access policy. |
analytics_pii_policy:write | Add or update permitted test recipients and sender domains. |
analytics_pii_policy:delete | Remove entries from the test-data access policy. |
billing:read | View billing information for the workspace, subject to billing-account ownership checks. |
billing:manage | Manage billing and eligible parent-to-child credit transfers; Owner and billing-account checks also apply. |
audit:read | View the team permission audit log, including membership, role, and permission changes. |
support_page:read | View operational support incidents. |
support_page:create | Check paging availability and create an urgent support ticket/operational page; availability and entitlement checks still apply. |
Domains and delivery
| Keyword | What it allows |
|---|---|
domain:read | View domains and domain groups. |
domain:write | Add or update domains and domain groups. |
domain:delete | Remove domains or domain groups. |
domain_dns:read | Inspect DNS, verification, DKIM, BIMI, tracking, and inbound-domain configuration. |
domain_dns:write | Run domain verification or change supported DNS, tracking, and inbound-domain configuration. |
smtp:read | View SMTP credential configuration. |
smtp:write | Create or update SMTP credentials. |
smtp:delete | Delete SMTP credentials. |
ip_pool:read | View IP pools. |
ip_pool:write | Create or update IP pools. |
ip_pool:delete | Delete IP pools. |
suppression:read | View suppressed recipients. |
suppression:write | Add or update suppressions. |
suppression:delete | Remove suppressions. |
compliance_template:read | View compliance templates and associated approval-request resources. |
compliance_template:write | Create or update compliance templates and associated approval-request resources. |
compliance_template:delete | Delete compliance templates or associated approval-request resources. |
Contacts and audiences
| Keyword | What it allows |
|---|---|
contact:read | View contacts and custom fields. |
contact:write | Create, import, or update contacts and custom fields. |
contact:delete | Delete contacts or custom fields. |
subscription_group:read | View subscription groups. |
subscription_group:write | Create or update subscription groups. |
subscription_group:delete | Delete subscription groups. |
segment:read | View audience segments. |
segment:write | Create or update segment definitions. |
segment:delete | Delete segments. |
segment:execute | Recalculate segment membership. |
Content and automation
| Keyword | What it allows |
|---|---|
email_template:read | View workspace email templates. |
email_template:write | Create or edit workspace email templates. |
email_template:delete | Delete workspace email templates. |
campaign:read | View campaigns. |
campaign:write | Create or edit campaign drafts. |
campaign:delete | Delete campaigns. |
workflow:read | View workflows. |
workflow:write | Create or edit workflow definitions. |
workflow:delete | Delete workflows. |
factory_email_template:read | Browse the built-in template repository. Importing a template also requires email_template:write. |
email_template_ai:generate | Generate AI templates or upload AI preview assets; also requires email_template:write and available quota. |
campaign:execute | Schedule, start, pause, resume, stop, or otherwise execute supported campaign lifecycle actions. Approval and send-readiness checks still apply. |
workflow:execute | Activate, pause, resume, or otherwise execute supported workflow lifecycle actions. Approval and readiness checks still apply. |
campaign:approve | Approve campaign content; does not itself grant drafting or execution. |
email_template:approve | Approve template content; does not itself grant editing or sending. |
workflow:approve | Approve workflow content; does not itself grant editing or execution. |
Credentials and integrations
| Keyword | What it allows |
|---|---|
api_key:read | View supported API-key resources across key types. |
api_key:write | Create or update supported API keys across key types. |
api_key:delete | Delete supported API keys across key types. |
marketing_api_key:read | View Marketing API keys. |
marketing_api_key:write | Create or update Marketing API keys. |
marketing_api_key:delete | Delete Marketing API keys. |
transactional_api_key:read | View Transactional API keys. |
transactional_api_key:write | Create or update Transactional API keys. |
transactional_api_key:delete | Delete Transactional API keys. |
web_api_key:read | View Web Setup API keys. |
web_api_key:write | Create or update Web Setup API keys and their allowed scopes. |
web_api_key:delete | Delete Web Setup API keys. |
webhook:read | View webhook configuration. |
webhook:write | Create or update webhook configuration. |
webhook:delete | Delete webhooks. |
integration:read | View integration configuration and connection status. |
integration:write | Configure or update integrations. |
integration:delete | Remove integration connections. |
webhook:execute | Run supported webhook test or retry actions. |
integration:execute | Run supported integration sync or execution actions. |
Mailbox and reporting
| Keyword | What it allows |
|---|---|
inbox:read | View received messages, sent items, threads, search results, and drafts for authorized mailboxes. |
inbox:write | Change message state, including read/unread and moving messages to trash. Requires explicit mailbox access; does not manage mailbox identities. |
inbox:delete | Delete mailbox messages or sent items; this does not authorize deleting mailbox configuration. |
analytics:read | View aggregate statistics and workspace activity. |
analytics:write | Defined analytics mutation capability; the current central route map does not assign an analytics-write action. |
email_event:read | View email events, live events, and the Sandbox Virtual Inbox, subject to data redaction. |
email_event:write | Add or update email-event annotations. |
email:send | Send email and use authorized sender identities. Does not grant received-mail access. Draft mutations also require inbox:read; verification, mailbox assignment, balance, and plan limits still apply. |
email_event_recipient:read | Reveal recipient identity on readable email events, subject to workspace data-access policy. Does not grant event-list access by itself. |
email_event_subject:read | Reveal subjects on readable email events. Does not grant event-list access by itself. |
email_event_diagnostics:read | Reveal delivery diagnostics on readable email events. Does not grant event-list access by itself. |
mailbox:read | View mailbox and send-only identity configuration under Account → Mailboxes. Does not grant message access. |
mailbox:write | Create receiving mailboxes or send-only identities and assign/revoke member access. Includes mailbox:read and a restricted eligible-domain picker; does not grant domain-page access. |
mailbox:delete | Delete mailbox or send-only identity configuration. Separate from deleting messages; mailbox:read is needed to use the Account management screen. |
Virtual Inbox
Virtual Inbox is the read-only inbox for simulated messages. In a Sandbox workspace, open Virtual Inbox from the left navigation. Select Transactional or Marketing, choose a test mailbox, then select a message to review its rendered content, lifecycle events, and message source.
It is not an externally reachable mailbox and it cannot receive replies. It exists so you can inspect what Simply Send accepted and the exact event sequence it simulated. Message source is retained with the email so you can inspect headers and MIME content during the five-day retention window.
Workspace FAQ
Is a legacy workspace live or sandbox?
Legacy workspaces without a type are treated as Live workspaces.
Can a child have another child?
No. Simply Send supports one parent-child level. A child workspace cannot be used as a parent.
Does being an Admin on a parent make me an Admin on every child?
No. Memberships and roles are workspace-specific. The person who creates a child starts as its Owner; other users must be added to that child separately.
Can an Admin create a child workspace?
Yes, when they have team:write on an eligible parent workspace and that parent has remaining child-workspace capacity.
Can I create a sandbox under a sandbox?
No. A sandbox must be a direct child of a paid Live workspace.
Do sandbox sends reach real recipients?
No. Every To, Cc, and Bcc address must be on the fixed sandbox test-data allow list. Any other address is rejected.
Does a sandbox affect sender reputation or production suppression lists?
No. Sandbox sends are simulated and do not call an external email provider or change production sender reputation.
How long are sandbox emails and events available?
Sandbox content, records, analytics, and events are retained for five days. Cleanup is asynchronous, so removal is not guaranteed at an exact time.
Can I use a sandbox domain in a Live workspace?
No. Mock verification is sandbox-only. A Live workspace must complete normal domain verification before sending.
Why does a sandbox send say there are insufficient credits?
Sandbox sends use the sandbox workspace’s own email balance. Transfer credits from the billing-owner parent workspace, then retry.