Copying Configurations¶
Waulter's configuration duplication feature lets you create copies of existing configurations — enabling a powerful template-based workflow for managing consent across multiple websites.
How to duplicate a configuration¶
- Navigate to the configuration you want to copy in the dashboard.
- Click the Duplicate or Copy action.
- Enter a name for the new configuration.
- The new configuration is created with all settings from the original.
- Adjust domain-specific settings:
- Update the website URL to the new domain
- Update whitelisted domains
- Review and adjust any domain-specific texts or settings
- Activate the new configuration when ready.
What is copied¶
| Copied | Not copied |
|---|---|
| All purpose categories and their settings | Statistics and consent records |
| Banner text and translations | Configuration ID (a new one is generated) |
| Styling (template, colours, fonts, icon) | Active state (new configs start inactive) |
| GCM mode settings | Whitelisted domains (must be set for new domain) |
| Consent durations | |
| Linked document references |
New Configuration ID
The duplicated configuration receives a new, unique Configuration ID. You must use this new ID when deploying the SDK on the target domain.
The template pattern¶
For agencies and organisations managing multiple websites, the template pattern provides an efficient workflow:
Create a master template¶
- Create a configuration with your standard settings (purposes, styling, texts, GCM mode).
- Name it clearly as a template — e.g.
[TEMPLATE] Standard EU Banner. - Keep the template configuration inactive — it is a blueprint, not a live config.
Duplicate for each client or domain¶
- Duplicate the template.
- Name the new configuration for the specific client or domain (e.g.
Client ABC — example.com). - Customise domain-specific settings:
- Website URL and whitelisted domains
- Client-specific colours, fonts, and logo
- Client-specific text adjustments
- Activate when ready.
Maintain templates over time¶
When standards change (e.g. new purposes, updated legal text):
- Update the template configuration with the new settings.
- Duplicate the updated template for each affected client.
- Review per-client customisations.
- Swap: activate the new copy, deactivate the old configuration.
Batch update workflow¶
When you need to update settings across multiple deployments:
flowchart TD
A["Update master template"] --> B["Duplicate to Client A"]
A --> C["Duplicate to Client B"]
A --> D["Duplicate to Client N"]
B --> E["Customise per-client settings"]
C --> E
D --> E
E --> F["Activate new configs"]
F --> G["Deactivate old configs"]
G --> H["Update SDK IDs if needed"] Step-by-step¶
- Update the template with the new settings (purposes, text, styling, etc.).
- Duplicate the template for each client/domain that needs the update.
- Customise per-client settings (domain, branding, any client-specific text).
- Test each new configuration using the Preview button.
- Activate the new configurations.
- Deactivate the old configurations.
- Update SDK deployment if the Configuration ID changed (not needed if using Scenario IDs — scenarios can be pointed to the new configuration).
Use Scenario IDs for zero-downtime updates
If your SDK uses a Scenario ID instead of a direct Configuration ID, you can update the scenario to point to the new configuration — no code change needed on the website.
Agency workflow¶
Agencies managing 10, 50, or 100+ client websites benefit most from the template pattern:
| Phase | Action |
|---|---|
| Onboarding | Duplicate template → customise for client → deploy |
| Routine update | Update template → duplicate to affected clients → swap active configs |
| Legal change | Update template text → roll out to all clients → verify compliance |
| New feature | Add to template → selective rollout to clients |
See the Agency Guide for the complete agency management workflow.
Best practices¶
- Name templates clearly — prefix with
[TEMPLATE]so they stand out in the configuration list - Keep templates inactive — templates are blueprints, not live configs
- Document customisations — track which settings differ per client so updates don't overwrite them
- Test before activating — always use the Preview button on new copies
- Archive old configs — deactivate rather than delete old configurations so you have a history