# Account Structure - Best Practices

**Accounts are isolated workspaces.** Items can’t be shared across accounts. **Containers**, created within an account, are the unit where tags, triggers, states, functions, and tools live—and **can be shared or reused across containers inside the same account**.\
This page explains how to structure accounts and containers for multi-domain, subdomain, and multi-tenant setups, and how identity sharing works via the [**Main Domain Cookie**](/key-features/main-domain-cookie.md).

## Key Takeaways

* **No cross-account sharing.** Treat accounts as separate entities.
* **Container-level reuse.** Within a single account, reuse configurations across multiple containers.
* **Subdomain strategy.** Most subdomain setups work cleanly with **one container**; you may still split by subdomain for organizational reasons.
* **Identity continuity.** Multiple containers on the same domain/subdomains can share a user ID via the **Main Domain Cookie** (configurable).

***

## Common Scenarios & Recommended Setups

### 1) One site, multiple country domains

**Example:** `example.at`, `example.de`, `example.ch`

<figure><img src="/files/5xZEkKsTjqpE2t6x7Bhw" alt=""><figcaption></figcaption></figure>

**Recommended:**

* **1 Account**, create **one Container per country domain**.
* Reuse shared configurations (Tools/Tags/Triggers/States/Functions) **across these containers** inside the same account.

**Why it works:**

* Keeps localization and governance clean per ccTLD, while centralizing shared logic.

***

### 2) One site with a shop subdomain

**Example:** `www.example.at` and `shop.example.at`

<figure><img src="/files/HFa5W3I5N6wq91Vcspyp" alt=""><figcaption></figcaption></figure>

**Step 1 — Confirm scope:**\
Check with your web manager whether `shop.example.at` is a **subdomain** of the same site or is operated as a **separate domain/site**.

**Step 2 — Read up on identity:**\
Review the [**Main Domain Cookie**](/key-features/main-domain-cookie.md) concept (see the dedicated article) to understand cross-container identity sharing options.

**Quick answer:**

* **If the shop is a subdomain:**
  * A **one-container strategy** is technically sound and commonly used.
  * You **don’t need multiple containers** for subdomains for technical reasons.
* **If you prefer more organizational separation:**
  * You can create **multiple containers**, one per subdomain.
  * It’s still easy to keep configurations in sync: select in each **Tool** which **Containers** it should apply to—scaling shared setups is a one-click operation.

**Identity behavior by default:**

* When you create **multiple containers for the same main domain and its subdomains**, they can **share data (user ID)** via the **Main Domain Cookie**.
* **Opt-out:** If you do **not** want data sharing between containers, disable the Main Domain Cookie feature in each relevant container.

***

### 3) Multiple owners (tenants) across different domains

<figure><img src="/files/4WeoQiD3zYP4tI4KgnnQ" alt=""><figcaption></figcaption></figure>

**Example:** Several independent stakeholders each responsible for their own domain(s).

**Recommended:**

* Create **separate Accounts**, each with their own Containers.
* **Note:** It is **not possible** to share DCP elements (Tools, Tags, Triggers, States, Functions) **across different accounts**.

***

### Main Domain Cookie (Overview)

The **Main Domain Cookie** enables a **shared user identifier** across multiple containers on the **same primary domain and its subdomains** (e.g., `example.at`, `shop.example.at`).

* **Use it when:** You want consistent identity and session logic across subdomains/containers.
* **Disable it when:** You require strict data isolation between containers (e.g., compliance or organizational boundaries).

See the [Main Domain Cookie](/key-features/main-domain-cookie.md) article for setup details, edge cases, and privacy considerations

***

### How to Reuse Configurations Across Containers (Same Account)

1. **Create or open a Tool** (or Tag/Trigger/State/Function) that should be shared.
2. **Select target Containers** inside the same account where the item should apply.
3. **Publish**—the configuration (including all settings) will be available everywhere you targeted.
4. **Maintain centrally**—update once, propagate to all selected containers.

**Benefits:** Faster scaling, consistent governance, and reduced configuration drift.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.jentis.com/core-concepts/jentis-account-and-container-structure/how-to-structure-your-account/account-structure-best-practices.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.