Groups and access control

Groups help larger organizations control who can see and use specific templates, integrations, folders, and related workflows.

note

Enterprise-only feature: Groups, template access restrictions, and integration access restrictions are available on Enterprise plans.

What this solves

Groups are useful when one Better Email organization supports multiple teams, brands, or business units that should not all share the same workflow.

Typical examples:

• business units
• brand teams
• regional teams
• B2B vs. B2C teams
• agency/client teams

Instead of assigning access one person at a time everywhere, admins can add users to groups and then reuse those groups when setting access rules.

How groups work

At a high level:

1. An admin creates a group.
2. The admin adds users to that group.
3. The group can then be used in access selectors across the product.

In the UI, groups live under organization settings, where admins can create groups, rename them, and manage membership.

TODO: Add a screenshot of the Groups settings page showing a few groups with member counts.

Where access control applies

When the feature is enabled, access restrictions can be applied to:

• templates
• integrations
• folders

This matters because access to one object affects the rest of the workflow:

• if a user cannot access an integration, they will not see it during export
• if a user cannot access a template, they should not rely on it for their day-to-day campaign workflow
• if a folder is restricted, email creation and organization naturally stay inside that team's workspace

Admins can always access everything, even when restrictions are in place.

The access model in practice

The core idea is simple:

1. use groups to represent stable team boundaries
2. scope templates, integrations, and folders to those groups where needed
3. let marketers work inside the set of assets they are allowed to see

That gives you controlled workflows without splitting everything into separate Better Email organizations.

Example 1: One brand, two marketing teams

Start with a simple example.

A mid-size company has:

• one brand
• one template
• one integration
• two teams: B2C and B2B

The team wants each group to stay in its own workspace, but both teams can still use the same brand system.

In this setup:

• both teams can use the same template
• both teams can export through the same integration
• folders are used to keep campaign work separated
• B2C editors create emails in the B2C folder
• B2B editors create emails in the B2B folder

This is a good pattern when the real difference is workflow separation, not brand system or ESP setup.

Example 2: Multiple BUs with multiple templates and integrations

Now take a larger organization with several business units.

Each BU has:

• its own top-level folder
• its own template or Email Design System
• its own integration
• its own group

The mapping is basically one-to-one.

In this setup:

• each business unit gets its own fully separated campaign workflow
• editors can create emails only in the folder(s) they have access to
• they only see the template(s) for their BU
• they only see the integration(s) for their BU at export time
• admins still have access to all BUs
• users who belong to more than one BU can work across all the assets shared with those groups

This is the strongest isolation model and is usually the right choice when business units have different brands, ESP accounts, compliance rules, or approval chains.

Example 3: Multiple BUs with one shared template / EDS

Some organizations want strong access control but do not want to maintain one template per BU.

In that case, you can keep:

• one shared template / Email Design System
• one folder per BU
• one integration per BU
• one group per BU

The shared template then carries the BU-specific behavior.

Typical ways to do that:

• add a global setting with a brand or BU select input
• drive visual differences like colors, logos, and footer details from template settings
• use shared template logic to branch output for each BU where appropriate

This pattern reduces template maintenance, but it asks more of the template itself. The template has to model brand differences cleanly without confusing marketers.

Driving BU branding from global.integrationId

The cleanest way to handle BU-specific branding in a shared template is to branch on the integration the email is being exported to. When an email renders, the selected integration is automatically exposed to the Global Script as global.integrationId. There is no input to configure — it is always available.

In the Global Script, you can then map each BU's integration to its own branding:

{% if global.integrationId == 1 %}
  {% set_global primary_color = "#FFF333" %}
  {% set_global logo_url = "https://cdn.example.com/bu-a/logo.png" %}
  {% set_global footer_text = "BU A • Legal footer" %}
{% elsif global.integrationId == 2 %}
  {% set_global primary_color = "#0044CC" %}
  {% set_global logo_url = "https://cdn.example.com/bu-b/logo.png" %}
  {% set_global footer_text = "BU B • Legal footer" %}
{% elsif global.integrationId == 3 %}
  {% set_global primary_color = "#A8161D" %}
  {% set_global logo_url = "https://cdn.example.com/bu-c/logo.png" %}
  {% set_global footer_text = "BU C • Legal footer" %}
{% endif %}

Modules then reference the resolved values as global.primary_color, global.logo_url, and so on, without knowing or caring which BU they are rendering for.

Because each BU group only has access to its own integration (see Example 2 above), this pattern lets you enforce per-BU branding directly from the EDS:

• a marketer in BU A only sees BU A's integration at export time
• their email is rendered with BU A's integrationId
• the Global Script swaps in BU A's colors, logo, and footer

There is no manual brand selector, no chance of marketers picking the wrong brand, and the template still serves every BU from one shared definition.

Choosing between the two multi-BU patterns

Use multiple templates when:

• each BU has a meaningfully different brand system
• the editor experience should be tightly constrained per BU
• teams should not even see each other's template structure

Use one shared template when:

• the structure is mostly the same across BUs
• differences can be handled through settings and template logic
• your team wants to minimize template maintenance

Rules of thumb

Best practices

• Keep group names business-readable.
• Create groups around stable team boundaries, not one-off campaigns.
• Prefer a small number of clear groups over many overlapping ones.
• Restrict templates, integrations, and folders only when the boundary is meaningful.
• Decide early whether your organization wants many templates or one shared EDS across BUs.
• Treat integrations as part of the access model, not just a technical export setting.
• Revisit group membership as the team changes.

Related docs

• Folders and access
• Integrations
• Templates