Vary email wording by business unit, brand, or region

Use property-specific messaging to send different privacy request emails for each business unit (BU), brand, or region from a single Privacy Center deployment. For example, one deployment at privacy.example.test can serve /example-brand/us, /example-brand/uk, and /example-brand/eu, each with its own wording. You do not need another deployment solely to change email copy.

Each path resolves to a property with its own privacy_center_config. Requests submitted through that property carry a property_id, which selects the email template for the message type when property-specific messaging is enabled. A region in a path is an explicit routing choice; it does not detect the visitor's location or language.

Before you start

• You need Owner or Contributor access to configure email templates.
• Configure an email messaging provider. Property-specific messaging supports email, not SMS.
• Use API-based Privacy Center configuration.
• For managed deployments, ask your account team to enable the deployment settings described below. For self-hosted deployments, apply them to the indicated service and restart it.

1. Create properties for the wording you need

In Settings > Properties, select Add a property and create a property for each combination that needs different copy, such as “Example brand US,” “Example brand UK,” and “Example brand EU.” Record each generated property ID. See creating a property.

Use properties consistently across your deployment: the same property_id can also affect privacy request dataset filtering. Review dataset assignments before using a new property for live requests.

2. Assign paths and Privacy Center configuration

For each property, use PUT /api/v1/plus/property/{property_id} to save its paths and complete privacy_center_config, following the property configuration guide. Preserve the property's other settings when updating it.

Assign distinct paths on the same Privacy Center domain:

Each property can use the same request actions and policies while displaying different copy. A path points to the property's Privacy Center configuration; it does not create another deployment.

To serve API configuration at the root path / as well, set this on the Privacy Center service:

FIDES_PRIVACY_CENTER__USE_API_CONFIG=true

See path routing for root-path and deployment details.

3. Create and enable templates for each property

In Management > Messaging, create or edit a template for each message type you need, assign the relevant property, customize the subject and body, and enable it. Repeat for the remaining properties. You can associate a template with multiple properties when they share wording; create separate templates when their copy differs.

For example, create a request-received template for each of the three properties, with a subject such as “Your Example brand UK privacy request.” Configure the other lifecycle messages you need, including completion and review messages. Preserve required placeholders such as verification codes and download links; see email template configuration and template types.

Review enabled templates on the default property too: requests without a property ID use it. Configure templates before enabling the mode so intended messages remain available during the change.

4. Enable property-specific messaging

The setting is notifications.enable_property_specific_messaging and defaults to false. Set its environment equivalent on the Fides API service:

FIDES__NOTIFICATIONS__ENABLE_PROPERTY_SPECIFIC_MESSAGING=true

Alternatively, set it in fides.toml:

[notifications]
enable_property_specific_messaging = true

In this mode, enabled templates determine which configurable emails are sent for each property. The basic-mode notification switches do not substitute for missing property templates.

5. Verify routing and email delivery

1. Open each configured path and confirm it displays that property's Privacy Center content.
2. Submit a test privacy request through each path. Confirm the resulting request carries the expected property_id; Privacy Center submissions attach it automatically.
3. Trigger each enabled lifecycle message and check the delivered subject and body against the property's template. A template preview alone does not verify routing.
4. Test a request without a property ID and confirm the default property's behavior. For direct API submissions, explicitly include the intended property_id; see programmatic requests.

Default-property fallback

For ordinary configurable messages without a requested locale:

• With a property_id, Astralis looks for an enabled template of that message type on that property. It does not automatically use the default property's template if that template is missing or disabled.
• Without a property_id, Astralis uses the default property to look up the enabled template.
• If no enabled template is found, the ordinary configurable message is not sent. Required messages, such as identity verification, have separate handling; do not use this rule to infer whether verification is required.

For requests that include a locale, see locale-specific templates.

What a property does and does not select

Property-specific messaging changes wording for an existing message type. Assigning a property does not itself select a language, change the processing outcome, or choose a policy-specific email variant.

Locale-specific templates (Astralis 3.1)

Astralis 3.1 added locale-specific templates. The setup steps above work the same in earlier releases, and this section only applies when a request includes a locale.

A region path does not set the locale. The locale comes with the request, separately from the property.

When a request includes a locale, Astralis picks the template in this order:

1. The property's enabled template for that exact locale.
2. The property's enabled locale-neutral template.
3. The default property's enabled locale-neutral template, but only if the property has no locale-neutral template at all. A disabled neutral template on the property still counts, so this fallback doesn't happen.

To keep each property's wording predictable, give each one its own locale-neutral template.

Astralis 3.1 also added outcome-specific message types, which you configure separately. See request types and email template types.