# Workspaces in Customer.io

Workspaces are a way of working with multiple products, sites or apps from a single Customer.io account. Everyone starts with one (its name is the same as your account name), and you can add or remove them as needed.

## Manage workspaces[](#manage-workspaces)

 To create, edit, or delete a workspace, you must be an [Account Admin](/accounts-and-workspaces/add-remove-team-members/#roles-and-permissions).

Click your workspace in the upper left corner and then click **Manage all workspaces** to see a list of your workspaces. From here you can add, edit or delete workspaces (if you have more than one).

[![Manage workspace settings](https://docs.customer.io/images/image%2868%29.png)](#a97508ab4cc23a420dbec297ce2b1937-lightbox)

### Add a workspace[](#add-a-workspace)

By default, new workspaces use both *email* and *id* as identifiersThe attributes you use to add, modify, and target people. Each unique identifier value represents an individual person in your workspace.. You can [change identifiers](#migrate-workspace) after you create your workspace.

 If you’re on our *Essentials* plan…

You can create two workspaces. If you already have two workspaces, you’ll either need to upgrade to our [Premium Plan](/journeys/plan-features/#premium-features) or [delete a workspace](#delete-a-workspace) first.

1.  To get to your [*Workspaces* page](https://fly.customer.io/settings/workspaces), click your workspace in the upper left corner and then click **Manage all workspaces**.
2.  Click **Add Workspace**.
3.  Give your new workspace a name and a custom color to help you differentiate between your workspaces.
    
    [![create-workspace.png](https://docs.customer.io/images/create-workspace.png)](#0a8b5090489d311c27dc7bfb5d4c7ea7-lightbox)
    
4.  Set the default send behavior for the workspace:
    *   **Send messages normally:** All messages send as defined in your workflow.
    *   **Test email delivery:** Emails will send to a defined test address; other messaging types (Slack, webhooks, etc.) send as normal.
    *   **Never send messages:** Message delivery is disabled.
5.  (Optional) [Disable open tracking for emails.](#disable-open-tracking)
6.  Select the team members who can manage and access the new workspace. You can’t disable access to a workspace for an Account Admin; Account Admins can access all workspaces in an account.
7.  Click **Save**.

When you’ve finished adding your workspace, you can switch between workspaces from the main navigation bar.

![Switch workspaces](https://docs.customer.io/images/change-workspace.gif)

### Edit a workspace[](#edit-a-workspace)

To edit an existing workspace, go to the *Workspaces* page and click ‘Edit’ in the Manage settings:

[![Edit a workspace](https://docs.customer.io/images/image%2870%29.png)](#a86eb19260a8b18d4a2fee3df392cf82-lightbox)

You can change your workspace’s name, delivery settings or access permissions for team members. You can also change the color assigned to the workspace to help you differentiate between them.

### Delete a workspace[](#delete-a-workspace)

Deleting a workspace permanently removes all data associated with the workspace—including campaigns, emails, people, etc. You may want to export your data before you delete a workspace.

To remove a workspace, go to the *Workspaces* page and click **Delete**. You must type your workspace’s name (case-sensitive) to delete it.

 Deleted workspaces are not recoverable.

Deleting a workspace **permanently** deletes all campaigns, emails, customers, deliveries, metrics, and data contained within a workspace. Make sure you’re prepared to lose this data before you delete a workspace.

## General workspace settings[](#general-workspace-settings)

After you create a workspace, you can change settings by going to **Settings** > **Workspace Settings** > **General Workspace Settings**.

[![General workspace settings page](https://docs.customer.io/images/general-workspace-settings.png)](#cc1cd2e915448feaa44c010987114a49-lightbox)

This is where you define the identifiers for people, which you need to add or update people in your workspace. You’ll decide how to identify people by `email` and/or `id`. You can always identify people by `cio_id`.

This chart shows what it means to update `email` or `id` based on these settings:

### Enable or disable email as an identifier[](#migrate-workspace)

New workspaces treat *email* as an identifierThe attributes you use to add, modify, and target people. Each unique identifier value represents an individual person in your workspace. by default, but you can disable it. Disabling email as an identifier only prevents you from using an email address to add or update people; you can still use it as an [attributeA key-value pair that you associate with a person or an object—like a person’s name, the date they were created in your workspace, or a company’s billing date etc. Use attributes to target people and personalize messages.](/journeys/attributes/).

The default configuration—in which email is an identifier—can be helpful for cases where you initially identify people who are interested in your product (leads) by email address and then assign them IDs later, when they become customers.

When you enable *email* as an identifier, we’ll [automatically merge people](/journeys/merge-people/) who have the same address.

 Changing your workspace identifiers may delay processing of people and event data

It can take up to a day to revalidate your data based on your new configuration settings. During this time, your workspace pauses processing people and event data and your [Workspace performance dashboard](https://fly.customer.io/workspaces/last/health) will reflect this. Processing resumes once validation is complete; no data is dropped.

To enable or disable email as an identifier:

1.  Go to [**Settings** > **Workspace Settings**](https://fly.customer.io/workspaces/last/settings/edit) and click **General Workspace Settings**.
2.  Click **update your workspace** next to `email`.
    
    [![change workspace identifiers](https://docs.customer.io/images/enable-identifiers.png)](#bafb4222e75aac2a7d4108a64bc47308-lightbox)
    
3.  Carefully read about the behaviors that will change for your workspace. When you’re ready, click **Change configuration**. If you’re enabling *email* as an identifier, we’ll [merge people](/journeys/merge-people/) that have the same email addresses.

#### Behaviors for people with an email but not an ID[](#multi-id-behavior)

When you enable email or ID as identifiers, you may notice slightly different behaviors from other workspace types.

*   **Reporting Webhooks**: the `customer_id` key is null if you add a person without an ID (by email only). You should update your endpoints to use the new `identifiers` object. See our [webhook documentation](/journeys/webhooks/#the-identifiers-object) for more information.
*   **Segment Source events**: After you migrate, message opens, clicks, etc. for people without an `id` are sent with the `email` address as an `anonymousId`. You can map these anonymous events to another destination or drop them.

#### Allow updates to email using ID[](#update-email-with-id)

If your workspace uses both email and ID as identifiersThe attributes you use to add, modify, and target people. Each unique identifier value represents an individual person in your workspace., this setting determines the requirements to change a person’s `email` after you set it. If you created your workspace after January 28, 2022, this setting is on by default.

[![Allow updates to email using ID setting](https://docs.customer.io/images/change-email-with-id.png)](#50bf69ead93220cfb125f2b2b130add0-lightbox)

In general, if you see a lot of failed “Attribute Change” requests in your workspace, or a significant number of your `identify` calls fail, you might try turning this setting on. You can also try enabling the [Multi-identifier profile merge](/journeys/merge-people/#auto-merge).

*   **cio\_id**: you must identify a person by `cio_id` to change their email address.
    
    A person’s `cio_id` is set when you create them, and is immutable. It acts as a canonical identifier across changes to a person’s `id` or `email`.
    
    For example, imagine that a person already has an `email` address and you want to change it. The request on the left below identifies a person by their `cio_id` and would succeed. The one on the right would fail.
    
    Successful request
    
    Failed request
    
    ```fallback
      curl --request PUT \
      --url https://track.customer.io/api/v1/customers/cio_1234 \
      --header "Authorization: Basic $(echo -n site_id:api_key | base64)" \
      --header 'content-type: application/json' \
      --data '{"email":"new.email@example.com"}'
    ```
    
    ```fallback
      curl --request PUT \
      --url https://track.customer.io/api/v1/customers/id1234 \
      --header "Authorization: Basic $(echo -n site_id:api_key | base64)" \
      --header 'content-type: application/json' \
      --data '{"email":"new.email@example.com"}'
    ```
    
*   **cio\_id** or **id**: you can change a person’s email address in any request that includes a person’s `id`.
    
    This makes it significantly easier to change your audience’s email address using our JavaScript snippet, [the API](/api/track/#operation/identify), any of our reverse ETL integrations and so on.
    

 This setting does not effect CSV imports

You cannot change a person’s `email` using a CSV import *unless* you use the *Update* setting and identify people by their `cio_id`.

### Message sending[](#message-sending)

Under “How do you want to send messages?” you can choose from:

1.  Send messages normally
2.  Send emails to a test address—note that this only applies to emails
3.  Never send messages

[![An image of the middle of general workspace settings. The section is titled: How do you want to send messages? There are three options from left to right. On the left is: send messages normally. In the middle is: send emails to a test address. On the right is: never send messages. Send emails to a test address is selected and highlighted in blue. There is a dropdown field where the email address ami@customer.io is selected.](https://docs.customer.io/images/workspace-settings-message-sending.png)](#16b002263ba0ac96facf222586740b31-lightbox)

When you first sign up for Customer.io, your account will *send emails to a test address*. This lets you send emails to a person in your account without verifying a domain so you can test your emails right away. You can see who will receive test emails in the top-left of your workspace. If you’ve integrated with other channels like in-app, those will send normally when “send emails to a test address” is selected.

 How test mode affects sending

While your workspace is in test mode, all emails are sent from Customer.io’s test domain and address ([test@customeriotest.com](mailto:test@customeriotest.com)) rather than your own verified domain. Because of this, you can’t select your own verified domains for sending, and we can’t track metrics like delivered, opened, and clicked back to your workspace.

This keeps test activity from affecting your actual campaign metrics. To send from your own domain, verify your domain and switch to Send messages normally.

[![An image of the top menu of a workspace. In the top-left is the workspace name: Ami Academy. To the right is a yellow banner that states: Emails send to ami@customer.io.](https://docs.customer.io/images/test-delivery-mode.png)](#d246538c04ffbb9cab452a4e0f17194d-lightbox)

By default, we’ll send test emails to the address that created the account. [*Account Admins* and *Workspace Admins*](/accounts-and-workspaces/add-remove-team-members/#roles-and-permissions) can select another team member to receive test emails from the dropdown. The address for “send emails to a test address” is the same for all team members in the workspace; it’s not unique to each team member.

After you [verify your domain](https://customer.io/journeys/authentication/) and are ready to send emails, click **Send messages normally**. Unless you are explicitly sending a test email, this setting ensures your messages send to actual recipients, as specified in the *To* field of your message.

You can also choose to **Never send messages** of any type (email, in-app, etc.). This disables all message delivery and ensures no one can receive a message from any campaign, broadcast, or transactional message. You might choose this option for test workspaces.

### Disable open tracking[](#disable-open-tracking)

Open tracking relies on a tracking pixel—a small image—in your messages; when a user opens an email containing the tracking pixel, the image loads from a remote location and tells us that a user opened the message.

However, open tracking is not always reliable. In the interest of user privacy, Apple and the makers of other email clients offer options to prevent images like tracking pixels from loading when users open messages; this prevents us from tracking open events. In some cases, email clients and corporate firewalls immediately download images when a person receives an email, causing us to record an open even if a person didn’t actually open the message.

To disable open tracking at the workspace level and prevent tracking pixels from being added to your emails entirely, you can go to [**Settings** > **Workspace Settings** > **General Workspace Settings**](https://fly.customer.io/workspaces/last/settings/edit). This setting overrides the message-level *Track opens and link clicks in this message* setting. Disabling open tracking this way can help you both respect your audience’s privacy and prevent you from focusing on sometimes-unreliable open rates, as opposed to clicks or conversions.

[![disable open tracking when you create or manage your workspace](https://docs.customer.io/images/disable-open-tracking.png)](#706048c36e79d18ac48bb626b56f0b4c-lightbox)

When you disable open tracking, open metrics for emails may still appear in some charts or tables (in campaign metrics, etc), but will always show zero results.

Whether you continue to track opens or not, we recommend setting conversion criteria for your messages and tracking link clicks as [more reliable ways to determine the success of your messages and campaigns](https://customer.io/blog/apple-is-late-to-the-party-marketers-stopped-trusting-open-rates-years-ago/).

### Assign workspace access[](#workspace-permissions)

If you isolate workspaces by project, client, app, etc, you may want to limit who has access to each workspace. You assign access based on workspace, so your team members can have full access to one workspace and partial access to another.

Only Account Admins can manage access for [team members](/accounts-and-workspaces/add-remove-team-members/#how-it-works). They can change access when:

*   creating or editing a workspace
    
    [![At the bottom of workspace settings is a table titled, Who should have access to this workspace? Three team members are listed. On the left are their names and email addresses. On the right are their workspace-level roles.](https://docs.customer.io/images/team-member-edit-workspace.png)](#e17139ae62f3f69247d78f17956aeb23-lightbox)
    
*   adding or editing team members
    
    [![The page header reads, Invite team member. The role Workspace admin is selected for all workspaces.](https://docs.customer.io/images/team-member-invite-page.png)](#7d34f36a36f71bcf47a9c892ebd26703-lightbox)
    

Account Admins have access all workspaces in the account. You cannot disable an Account Admin’s access to a workspace.

## FAQs[](#faq)

### What data is shared across workspaces?[](#what-data-is-shared-across-workspaces)

No information is shared between workspaces.

Workspaces are essentially separate instances of Customer.io. Each workspace has its own people, campaigns, metrics, and other data.

### How is billing calculated across workspaces?[](#how-is-billing-calculated-across-workspaces)

We bill based on people, objects, emails sent, and Data Pipelines API calls across all your workspaces. Check out [How We Bill](/accounts-and-workspaces/how-we-bill/) for more info.

### Is there any way of sharing data between workspaces?[](#is-there-any-way-of-sharing-data-between-workspaces)

Workspaces are completely separate instances of Customer.io, each with their own people and associated data. This prevents sharing information and potentially messaging the wrong person. However, you can [copy workflow actions across workspaces](/journeys/copying-workflow-items/).

### What about testing? Are workspaces a way to do that?[](#what-about-testing-are-workspaces-a-way-to-do-that)

Although not designed specifically for testing, workspaces *can* be used as a sandbox to set up testing/staging environments. Each workspace is assigned its own set of API keys and are completely separate from your other workspaces. Once you’re ready to migrate a Campaign or message from test to production, you can [copy entire workflow actions](/journeys/copying-workflow-items/) from one campaign to another across workspaces.

### How do I move a workspace to another account?[](#how-do-i-move-a-workspace-to-another-account)

To move a workspace from one account to another, you’ll need to contact Customer.io support. This process requires manual assistance from our team to ensure data integrity and proper migration. Click **Need help?** at the top of your workspace and then submit your request through **Get help with an issue**.