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
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 sender (name & address) | The property can override the name and address email is sent from, or inherit the organization's when left blank. |
| Email templates | Resolved per property, then falling back to the organization, then the built-in default. |
| Branding | Each token, component variable, and the logo can be overridden per property, inheriting the organization's value otherwise. |
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).
Managing properties requires the same permission as managing the organization. Anyone who can edit organization settings can create, configure, and delete properties. See Permissions.
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) Choose from the domains already added to your organization. Leave unset to use the default web address. |
Custom Domain is a list, not free text — it only offers domains already added to your organization and not already assigned elsewhere. Adding a new domain is not a self-service action from Property Settings; if the domain you need isn't listed, ask your platform administrator to add it.
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.
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
Each property has its own settings area, reached by clicking a property in the Properties list. The left navigation has five sections: General, Branding, Browser Settings, Email Settings, and Email Templates.
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, chosen from the domains available to your organization. Leave unset to use the default subdomain. |
A custom domain is provisioned by your platform administrator before it can be selected here — this page only lets you assign an already-available domain to this property, not add a new one. DNS and certificate setup are handled when the domain is added to your organization; this page never asks you to configure DNS. For how custom domains are served and routed, see the developer guide on Properties.
Every setting on this page saves together. If this property's custom domain is ever no longer available to your organization (for example, it was removed from your organization's inventory), you cannot save any change here — not just the domain — until you select a currently available domain or clear the field. Ask your platform administrator to re-add the domain if you need to keep using it.
Branding
The Branding page lets a property override the organization's branding — its logo, global design tokens, and per-component variables — so the Allegro components embedded on that property's pages can carry a distinct visual identity. It uses the same editor as organization branding, with one difference: anything a property leaves unset inherits the organization's value.
Inheritance works per value:
- Every design token and component variable falls through to the organization's value (and then the built-in default) until you give it a property-specific value. Inherited values appear as placeholders, and a small dot marks the ones you have overridden for this property.
- The logo is atomic: a property logo replaces the organization's entirely when set, and removing it falls back to the organization's logo.
- Clearing a value returns it to inheriting, so an organization rebrand still flows through to a property automatically for anything the property hasn't overridden.
The live preview renders the true merged result — the property's overrides layered on top of the organization's branding — and each property's branding keeps its own revision history, so you can browse, compare, and roll back a property's branding independently of the organization's.
For how the branding design system, inheritance, and revisions work in general, see Branding.
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
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
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 Settings
The Email Settings page controls the sender identity for email sent through this property — the name and address it comes from. This lets each property send under its own identity while still using the organization's email delivery configuration.
| Field | Description |
|---|---|
| From Name | The display name recipients see (e.g. Acme News). |
| From Address | The address email is sent from (e.g. [email protected]). |
Leave a field blank to inherit the organization's value — when it inherits, the page shows the organization value it is falling back to. The resolution is the familiar three tiers: property → organization → built-in default.
Click Send test email to send a test message to your own email address using this property's saved sender settings, so you can confirm the identity looks right before real email goes out. Save any changes first — the test uses the saved values, and a provider rejection (such as an unverified From Address) is reported to you directly.
Only the sender name and address are set per property. The underlying email delivery credentials (AWS SES) remain an organization-wide setting — see Settings → Email.
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.
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.
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
- Properties (Developer) — host format, custom domains, and how the SDK targets a property
- Settings — organization-wide configuration
- Email Templates — organization-wide transactional email
- Permissions — who can manage properties