# Properties

Properties let a single organization operate more than one property from one Allegro account. A media company might run two publications as separate properties under one organization; a publisher might separate a flagship publication from a newsletter product. Each property has its own web address and its own browser and email configuration, while sharing the organization's members, entitlements, templates, and reporting.

You do not need properties to use Allegro. If your organization is a single brand, the organization-level settings are all you need. Add properties only when you have distinct properties that must present a different domain or send email under a different identity.

## How Properties Relate to Your Organization[​](#how-properties-relate-to-your-organization "Direct link to How Properties Relate to Your Organization")

A property is scoped to your organization and inherits everything the organization defines. It layers a small number of property-specific overrides on top:

| Area                             | Behavior with properties                                                                 |
| -------------------------------- | ---------------------------------------------------------------------------------------- |
| Members, entitlements, purchases | Shared across the whole organization — a member is the same person on every property.    |
| Templates and interactions       | Shared across the whole organization.                                                    |
| Reporting and analytics          | Shared across the whole organization.                                                    |
| Web address                      | Each property has its own subdomain, and optionally its own custom domain.               |
| CORS allowed origins             | The property **adds** its origins on top of the organization's — it never removes them.  |
| Cookie domain                    | The property can **replace** the organization's, or inherit it when left blank.          |
| Email templates                  | Resolved per property, then falling back to the organization, then the built-in default. |

## The Properties List[​](#the-properties-list "Direct link to The Properties List")

Go to **Organization Settings → Properties** to see every property in your organization. The list shows each property's name, slug, and custom domain (if one is set).

Who can manage properties

Managing properties requires the same permission as managing the organization. Anyone who can edit organization settings can create, configure, and delete properties. See [Permissions](/product/administration/permissions.md).

## Creating a Property[​](#creating-a-property "Direct link to Creating a Property")

Click **New Property** from the Properties list and provide:

| Field             | Description                                                                 |
| ----------------- | --------------------------------------------------------------------------- |
| **Name**          | The display name shown throughout the dashboard. You can change this later. |
| **Slug**          | The permanent identifier used in the property's web address.                |
| **Custom Domain** | *(Optional)* A domain you control that serves this property.                |

### Slug Rules[​](#slug-rules "Direct link to Slug Rules")

The slug becomes part of the property's web address, so it has strict formatting rules:

* Lowercase letters, numbers, and single hyphens only.
* **No consecutive hyphens.** A double hyphen (`--`) is reserved as the separator between your organization and the property in the web address.
* Up to 63 characters.
* Must be unique within your organization.

Slugs are permanent

A property's slug **cannot be changed after the property is created**. It is baked into the property's web address and its saved configuration. Choose it carefully. To use a different slug, delete the property and create a new one.

Once created, you are taken to the property's **General** settings, where the rest of its configuration lives.

## Property Settings[​](#property-settings "Direct link to Property Settings")

Each property has its own settings area, reached by clicking a property in the Properties list. The left navigation has three sections: **General**, **Browser Settings**, and **Email Templates**.

### General[​](#general "Direct link to General")

The General page shows the property's name, its (read-only) slug, and its custom domain.

| Field             | Description                                                                                               |
| ----------------- | --------------------------------------------------------------------------------------------------------- |
| **Name**          | Editable display name.                                                                                    |
| **Slug**          | Read-only. Set at creation and permanent.                                                                 |
| **Custom Domain** | The domain that serves this property's audience-facing traffic. Leave blank to use the default subdomain. |

A custom domain must be unique across your entire Allegro instance — it cannot match another organization's domain or another property's domain. DNS for the domain must point to your Allegro instance. For how custom domains are served and routed, see the developer guide on [Properties](/developer/guides/properties.md).

### Browser Settings[​](#browser-settings "Direct link to Browser Settings")

The Browser Settings page controls how this property's pages interact with the Allegro SDK in a member's browser. These mirror the organization's browser settings but apply only to this property.

| Setting                  | Description                                                           |
| ------------------------ | --------------------------------------------------------------------- |
| **CORS Allowed Origins** | The web origins allowed to call this property's API from the browser. |
| **Cookie Domain**        | The domain the session cookie is scoped to for this property.         |

#### CORS Allowed Origins[​](#cors-allowed-origins "Direct link to CORS Allowed Origins")

Each origin is a full origin such as `https://acme.com`. Wildcard subdomain origins are supported in the form `https://*.acme.com`.

The property's origins are **added on top of** the organization's allowed origins — configuring them here never removes origins the organization already allows. The property's own web address is always allowed automatically.

#### Cookie Domain[​](#cookie-domain "Direct link to Cookie Domain")

Set a cookie domain (for example `.acme.com`) so member sessions are shared across that property's subdomains. If you leave this blank, the property **inherits the organization's cookie domain**. Setting a value here replaces the organization's value for this property only.

### Email Templates[​](#email-templates "Direct link to Email Templates")

Each property can customize the transactional emails Allegro sends — such as magic sign-in links — so they match that property's brand. The Email Templates page lists every email type and shows where its current content comes from:

| Source           | Meaning                                                                                           |
| ---------------- | ------------------------------------------------------------------------------------------------- |
| **Property**     | This property has its own customized template.                                                    |
| **Organization** | No property override; the organization's template is used.                                        |
| **Default**      | Neither the property nor the organization has customized it; Allegro's built-in template is used. |

When you edit a template, the editor shows the inherited content (the organization's version, or the built-in default) alongside your property-specific version so you can see what you are overriding.

* **Send Test** sends a preview of the property's rendered template to your own email address.
* **Reset** removes the property override. The template then falls back to the organization's version, or the built-in default if the organization has not customized it either.

This three-tier resolution — **property → organization → default** — means you only need to override the emails that differ for a given property. Everything else inherits automatically.

For the organization-wide equivalent of this page, see [Email Templates](/product/email-templates.md).

## Deleting a Property[​](#deleting-a-property "Direct link to Deleting a Property")

Delete a property from its settings. Deleting a property removes its property-specific configuration — its browser settings, email template overrides, and custom domain mapping. It does **not** affect members, entitlements, or templates, which belong to the organization.

Deletion is permanent

Deleting a property permanently removes its configuration and frees its slug and custom domain. Any embed code pointing at the deleted property's web address will stop resolving.

## Related Links[​](#related-links "Direct link to Related Links")

* [Properties (Developer)](/developer/guides/properties.md) — host format, custom domains, and how the SDK targets a property
* [Settings](/product/administration/settings.md) — organization-wide configuration
* [Email Templates](/product/email-templates.md) — organization-wide transactional email
* [Permissions](/product/administration/permissions.md) — who can manage properties