More than one SendOps workspace can connect to the **same** AWS SES account. This is common when an agency manages SES for several clients, when different teams in one company each run their own workspace, or simply when the same company was onboarded twice by accident. This page explains how SendOps keeps everyone's analytics correct in that setup, what a **claim conflict** is, how to resolve one, and how paused events are safely replayed afterwards.

## Why workspaces see each other's identities

Every sync scans the **whole** AWS SES account, so a workspace discovers every domain, email identity, and configuration set (channel) in that account — including ones that really belong to a sibling workspace. SendOps shows these as **Discovered** with a "New" badge. Sending is never affected: channel configuration-set names are namespaced per workspace (`sesmail-{namespace}--{channel}`), so two workspaces never collide when sending.

What *can* be ambiguous is **incoming analytics events**. When SES reports an open, click, bounce, or delivery for an identity that two workspaces both claim, SendOps has to decide which workspace's reports and workflows that event belongs to. When it can't decide, a **claim conflict** exists.


  This page builds on [Account Sync](/aws-setup/account-sync), which covers the Discovered / Detached / Archived lifecycle and the sticky **Detach** for channels. Read that first if the lifecycle states below are unfamiliar.


## What a claim conflict is

A **claim conflict** happens when **two or more workspaces of one AWS account each hold a claim on the same sending identity — and none of them has adopted it** (all are still in the **Discovered** state).

- If exactly **one** workspace holds the identity, SendOps attributes its events there — no conflict.
- If exactly **one** workspace has **adopted** (activated) it, that workspace wins — no conflict.
- If **several** workspaces hold it and **none** has adopted it, SendOps cannot safely guess the owner. Rather than attributing events to the wrong workspace — or dropping them — it **pauses** those events until the conflict is resolved.

You'll see this inline banner on the **Channels**, **Identities**, and onboarding pages:

> **Claim conflict — events paused**
> "example.com" is also claimed by *Beta Workspace*. Its analytics events are paused until one workspace adopts it.
>
> *1,240 events waiting — they'll be imported automatically once the conflict is resolved.*


  While a conflict is open, matching events are held safely — **not** dropped. Once you resolve the conflict, every held event is imported automatically. See [What happens to paused events](#what-happens-to-paused-events-replay) below.


## Resolving a claim conflict

The goal is simple: **exactly one workspace should own each identity.** You resolve a conflict either by *adopting* the identity in the workspace that should own it, or by having the other workspaces *leave* it. The banner offers the right actions for each type:

| Type | Actions available | What it does |
|---|---|---|
| **Domain** | **Adopt here** | Claims the domain for this workspace (Discovered → Active). Its events are attributed here from now on, and every held event is replayed into this workspace. |
| | **Leave with *<workspace>*** | Detaches the domain from this workspace, leaving the sibling's claim intact. Clears the conflict when the domain belongs to them. |
| | **Move to this workspace** | Takes over a domain a sibling has **already adopted**. Needs the reassign permission in *both* workspaces. |
| **Email identity** | **Adopt here** | Claims the email identity for this workspace and attributes (and replays) its events here. |
| | **Leave with *<workspace>*** | Detaches the email identity from this workspace, leaving it with the sibling that owns it. |
| **Channel** | **Adopt here** | Claims the channel for this workspace (Discovered → Active) and adds its event destination in SES, so SendOps starts receiving events for that configuration set. |
| | **Detach from this workspace** | Hides the channel from this workspace without touching AWS. Use this when the channel belongs to a sibling. |
| | **Move to this workspace** | Takes over a channel that a sibling has currently adopted, moving ownership here. |

A conflict clears the moment ownership is unambiguous again — i.e. only one workspace holds the identity, or exactly one has adopted it.

**Adopt** and **Move to this workspace** are not the same action, and the banner only offers the one that applies:

- **Adopt** is for the normal case — *nobody* has claimed the identity yet. That is what a claim conflict is, so Adopt is almost always the action you want.
- **Move to this workspace** is for taking an identity a sibling has *already adopted*. It is not a way to resolve a conflict (in a conflict, by definition, no one has adopted), and it requires the reassign permission in the workspace that currently owns it.


  You only need **one** side to act. Either the owning workspace **adopts** the identity, or every other workspace uses **Leave with…** to step aside — either way ownership becomes unambiguous and the conflict clears. If you're unsure which workspace should own an identity, our support team can help you resolve it safely.



  Events are attributed by **sending identity** (the domain or email address a message was sent from), never by channel — so only a **domain** or **email identity** conflict pauses events. A conflicted *channel* is worth resolving to keep ownership clean, but adopting a channel will not release held events. If events are being held, look for the conflict on the identity.


These actions are permission-gated (`domains.adopt`, `domains.detach`, `domains.reassign`, `identities.adopt`, `identities.detach`, `channels.adopt`, `channels.detach`, `channels.reassign`). If a button is disabled, an admin on your workspace needs to grant the matching permission or perform the action.

### Detach is sticky

Detaching an identity or channel to resolve a conflict is **sticky**: because the underlying resource still exists in SES, sync will **not** re-add it on the next run, and the 30-day auto-archive sweep leaves it alone. If you detach something by mistake, use **Reattach** to bring it back to the Discovered state.

## What happens to paused events (Replay)

When a conflict pauses events, SendOps doesn't discard them — it holds each one aside with the identity and the list of workspaces that could own it. This is the safety net that guarantees you don't lose analytics while a conflict is being sorted out.

**Once you resolve the conflict:**

1. SendOps re-checks ownership now that it's unambiguous.
2. Every held event for that identity is **replayed** into the winning workspace — it lands in your reports, timelines, and workflow triggers just as if it had arrived normally.
3. Replay is **idempotent**: an event is only ever imported once, so resolving a conflict never double-counts opens, clicks, or bounces.

Replay happens automatically within a few minutes of resolution. **Adopting** or **moving** an identity kicks off the replay immediately; resolving by **Leave with…** (detach) instead relies on the background sweep, which runs every few minutes. Either way you don't need to do anything else — the "N events waiting" count in the banner drops to zero as they're imported.


  Held events are retained for **30 days** from the moment each one is held. Resolve the conflict within that window and nothing is lost. Events still held after 30 days expire and **cannot be recovered** — so treat a claim-conflict banner as something to action promptly, not ignore.


### You'll be notified

When a conflict persists, SendOps sends a **Claim conflict** notification (`system_infrastructure.claim_conflict`) to **admins of every workspace** involved, so both sides know to coordinate. It's rate-limited to at most once every 24 hours per conflict, and appears in-app and by email. See [Notification Types](/notifications/notification-types#system--infrastructure).

## Best practices for shared accounts

- **One workspace per brand or team.** Decide up front who owns each domain and channel. The cleanest setup is a single workspace that actively manages each identity.
- **Don't onboard the same company twice.** Accidentally creating a second workspace for a company that's already connected is the most common cause of claim conflicts. If you're an agency, connect each client once.
- **Adopt promptly during onboarding.** When you verify a domain and provision channels, adopt them in the workspace that will own them. This makes ownership unambiguous before events start flowing.
- **Detach what isn't yours.** If your dashboard shows a sibling workspace's identities as Discovered, use **Detach** / **Leave with…** to hide them. This keeps your view clean and prevents future conflicts on those identities.
- **Act on the banner quickly.** Because held events expire after 30 days, resolving conflicts within a few days guarantees a complete analytics history.
- **Coordinate across workspaces.** Both sides get the notification. Agree which workspace adopts and which steps aside, then resolve — replay does the rest.

## What's next?

- [Account Sync](/aws-setup/account-sync) — the Discovered / Detached / Archived lifecycle and sticky detach.
- [Understanding Channels](/channels/understanding-channels) — how channels map to SES configuration sets and stay namespaced per workspace.
- [Notification Types](/notifications/notification-types) — the full list of alerts, including claim conflicts.